Разделение MySQL против перехода на MangoDB

Question

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

Вот схема данных

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

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

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

Включите slowlog, соберите некоторые данные, запустите pt-query-digest и покажите нам "худший" запрос. Предоставлять EXPLAIN SELECT ... для этого.

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

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

Answer 2

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

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