Разделение MySQL или изменение на MangoDB

Question

У нас есть 4 довольно больших таблицы в базе данных MySQL. Они около 50, 35, 6 и 5 Гб, другие таблицы не такие большие. Эти таблицы полны аналитических данных, которые добавляются задачами cron каждые 10 минут. Эти таблицы будут продолжать расти со временем.

Вот схема из DataTable

CREATE TABLE `instpld` (
    `id` int(20) NOT NULL AUTO_INCREMENT, 
    `insID` varchar(100) NOT NULL, 
    `dbID` int(10) NOT NULL, 
    `type` varchar(1) NOT NULL, 
    `timestamp` int(11) NOT NULL, 
    `count` text NOT NULL, 
    `comment_count` int(10) NOT NULL, 
    PRIMARY KEY (`id`), 
    KEY `insID` (`insID`(50)), 
    KEY `dbID` (`dbID`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

Я понимаю, что типы полей могут быть намного лучше. Вопрос в том, что лучше - добавление некоторого разбиения на таблицу или переключение всего на MangoDB, потому что оно быстрее?

Я ищу плюсы и минусы каждого варианта.

# Misc Settings 
# ------------- 
datadir=/var/lib/mysql 
tmpdir=/var/lib/mysqltmp 
socket=/var/lib/mysql/mysql.sock 
#skip-locking 
skip-name-resolve 
#table_cache=2048 
thread_cache_size=16 
back_log=100 
max_connect_errors=10000 
open-files-limit=20000 
interactive_timeout=3600 
wait_timeout=600 
#max_connections=200 
# Added to prevent DNS lookups from causing performance issues 
skip-name-resolve 

# Set this to change the way MySQL handles validation, data 
# conversion, etc. Be careful with this setting as it can 
# cause unexpected results and horribly break some applications! 
# Note, too, that it can be set per-session and can be hard set 
# in stored procedures. 
#sql_mode=NO_ENGINE_SUBSTITUTION 

# Slow Query Log Settings 
# ----------------------- 
#log-slow-queries=/var/lib/mysqllogs/slow-log 
#long_query_time=2 
#log-queries-not-using-indexes 

# Global, Non Engine-Specific Buffers 
# ----------------------------------- 
max_allowed_packet=16M 
tmp_table_size=64M 
max_heap_table_size=64M 

# Generally, it is unwise to set the query cache to be 
# larger than 64-128M as this can decrease performance 
# since the penalty for flushing the cache can become 
# significant. 
query_cache_size=32M 
skip-name-resolve 

# Set this to change the way MySQL handles validation, data 
# conversion, etc. Be careful with this setting as it can 
# cause unexpected results and horribly break some applications! 
# Note, too, that it can be set per-session and can be hard set 
# in stored procedures. 
#sql_mode=NO_ENGINE_SUBSTITUTION 

# Slow Query Log Settings 
# ----------------------- 
#log-slow-queries=/var/lib/mysqllogs/slow-log 
#long_query_time=2 
#log-queries-not-using-indexes 

# Global, Non Engine-Specific Buffers 
# ----------------------------------- 
max_allowed_packet=16M 
tmp_table_size=64M 
max_heap_table_size=64M 

# Generally, it is unwise to set the query cache to be 
# larger than 64-128M as this can decrease performance 
# since the penalty for flushing the cache can become 
# significant. 
query_cache_size=32M 

# Per-Thread Buffers 
# ------------------ 
sort_buffer_size=1M 
read_buffer_size=1M 
read_rnd_buffer_size=8M 
join_buffer_size=1M 
key_buffer_size=64M 

# This setting controls the size of the buffer that is allocated when 
# sorting MyISAM indexes during a REPAIR TABLE or when creating indexes 
# with CREATE INDEX or ALTER TABLE. 
myisam_sort_buffer_size=64M 

# InnoDB 
# ------ 
# Note: While most settings in MySQL can be set at run-time, InnoDB 
# variables require restarting MySQL to apply. 

# If the customer already has InnoDB tables and wants to change the 
# size of the InnoDB tablespace and InnoDB logs, then: 
# 1. Run a full backup with mysqldump 
# 2. Stop MySQL 
# 3. Move current ibdata and ib_logfiles out of /var/lib/mysql 
# 4. Uncomment the below innodb_data_file_path and innodb_log_file_size 
# 5. Start MySQL (it will recreate new InnoDB files) 
# 6. Restore data from backup 
#innodb_data_file_path=ibdata1:2000M;ibdata2:10M:autoextend 
innodb_log_file_size=100M 

innodb_buffer_pool_size=2G 

........ 

Answer 1

Его действительно невозможно ответить, не зная, как вы его используете или каким узким местом вы столкнетесь в первую очередь.

Помните, что Innodb имеет некоторые проблемы с размером, если вы не оптимизируете таблицу время от времени.

Answer 2

У вас есть 128 ГБ, используйте его! innodb_buffer_pool_size=2G - изменить примерно до 70% оперативной памяти.

Держу пари, вы не можете показать мне EXPLAIN, который использует KEY instaID (instaID(50)). Индексы префиксов почти всегда не используются.

Включите медленный журнал, соберите некоторые данные, запустите pt-query-digest и покажите нам «худший» запрос. Укажите для него EXPLAIN SELECT ....

id int(20) NOT NULL AUTO_INCREMENT, - Надеюсь, вы не ожидаете 20-значных чисел. Это превысит немногим более 2 миллиардов.

Если мы не сможем оптимизировать ваши запросы, мы перейдем к методам хранения данных, таким как сводные таблицы - они, как правило, дают 10-кратное ускорение.