Масштабируемость использования MySQL в качестве базы данных ключ / значение

Question

Мне интересно узнать влияние на производительность использования MySQL в качестве базы данных ключ-значение по сравнению, скажем, с Redis / MongoDB / CouchDB. В прошлом я использовал Redis и CouchDB, поэтому я хорошо знаком с их вариантами использования и знаю, что лучше хранить пары ключ / значение, скажем, NoSQL против MySQL.

Но вот ситуация:

• основная масса наших приложений уже имеет множество таблиц MySQL
• Мы размещаем все на Heroku (который имеет только MongoDB и MySQL и в основном имеет тип 1-db на приложение)
• мы не хотим использовать несколько разных баз данных в этом случае.

Так что в основном я ищу информацию о масштабируемости наличия таблицы ключ / значение в MySQL. Может быть на трех разных уровнях:

• 1000 записей в день
• 1000 записей в час
• 1000 записей в секунду
• 1000 операций чтения в час
• 1000 операций чтения в секунду

Практический пример - создание чего-то вроде MixPanel Tracker Web Analytics в режиме реального времени , для которого очень часто приходилось бы писать в зависимости от трафика.

Wordpress и другие популярные программы используют это постоянно: у Post есть «мета» модель, которая является просто ключом / значением, так что вы можете добавлять произвольные свойства к объекту, который можно искать.

Другой вариант - хранить сериализуемый хэш в BLOB-объекте, но это выглядит хуже.

Что вы берете?

Answer 1

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

• размер данных, которые будут храниться в этой таблице KV
• уровень параллелизма, которого вы хотите достичь
• количество существующих запросов, достигающих вашего экземпляра MySQL

Я бы также сказал, что в зависимости от требований к долговечности дляНа этих данных вы также захотите протестировать несколько движков: InnoDB, MyISAM.

Хотя я ожидаю, что некоторые решения NoSQL будут быстрее, исходя из ваших ограничений, вы можете обнаружить, что MySQL будет работать достаточно хорошо для вашеготребования.

Answer 2

SQL базы данных все чаще используются в качестве постоянного уровня, при этом вычисления и доставка кэшируются в Key-Value хранилищах.

Имея это в виду, эти ребята провели здесь довольно серьезное испытание:

• InnoDB вставляет 43 000 записей в секунду при его пике *;
• TokuDB вставляет 34 000 записей в секунду НА ЕЕ ПИК *;
• Этот KV вставляет 100 миллионов записей в секунду (в 2000 и более раз).

Чтобы ответить на ваш вопрос, репозиторий Key-Value с большой вероятностью превзойдет MySQL на несколько порядков:

Обработка 100,000,000 предметов:

kv_add()....time:....978.32 ms
kv_get().....time:....297.07 ms
kv_free()....time:........0.00 ms

Хорошо, ваш тест был 1,000 операций в секунду, но это не помешает сделать в 1,000 раз больше!

См. this для получения более подробной информации (они также сравнивают его с Tokyo Cabinet).

Answer 3

Нет сомнений, что использование решения NOSQL будет быстрее, поскольку оно проще.
NOSQL и Relational не конкурируют друг с другом, это разные инструменты, которые могут решать разные проблемы.
ЭтоСчитается, что для 1000 операций записи в день или в час у MySQL не возникнет проблем.
Для 1000 операций в секунду вам понадобится какое-то причудливое оборудование, чтобы добраться туда.Для решения NOSQL вам, вероятно, все еще потребуется распределенная файловая система.

Это также зависит от того, что вы храните.

Answer 4

Ознакомьтесь с серией постов в блоге здесь , где автор проводит тесты, сравнивающие производительность MongoDB и MySQL, и борется с путаницей настройки производительности MySQL. MongoDB выполнял ~ 100K операций чтения строк в секунду, MySQL в режиме c / s делал максимум 43K, но с помощью встроенной библиотеки ему удалось получить до 172K операций чтения строк в секунду.

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

Писать / второй вопрос немного сложнее, но он все же может дать вам некоторые идеи по поводу конфигов.

Answer 5

Сначала вы должны реализовать это самым простым способом, а затем сравнить это. Всегда проверяйте вещи. Это значит:

• Создайте схему, соответствующую вашему варианту использования.
• Создание запросов, представляющих ваш вариант использования.
• Создание значительного количества фиктивных данных, представляющих ваш вариант использования.
• В различных циклах, включая как произвольный доступ, так и последовательный, отметьте его.
• Убедитесь, что вы используете параллелизм (запускайте множество процессов, случайным образом забивая сервер всеми видами запросов, представляющими ваши варианты использования).

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

Тогда попробуйте оптимизировать его.

В MySQL есть одно конкретное ограничение для KV - стандартные двигатели с постоянными индексами использования, оптимизированными для поиска по диапазону, а не для KV, что может привести к дополнительным издержкам, хотя также сложно заставить такие вещи, как хэш, работать с постоянным хранилищем из-за перепевы. Таблицы памяти поддерживают хэш-индекс.

Многие люди связывают определенные вещи с медлительностью, такие как SQL, RELATIONAL, JOINS, ACID и т. Д.

При использовании реляционной базы данных с поддержкой ACID необязательно использовать ACID или отношения.

Несмотря на то, что объединения имеют плохую репутацию медленных, это обычно сводится к неправильным представлениям о соединениях. Часто люди просто пишут плохие запросы. Это усложняется, так как SQL декларативен, он может ошибаться, особенно в соединениях, где часто есть несколько способов выполнить соединение. То, что люди на самом деле получают от NoSQL в этом случае, обязательно. NoDeclaritive будет более точным, так как это проблема с SQL, которая возникает у многих людей. Нередко людям просто не хватает индексов. Это не аргумент в пользу объединения, а скорее для того, чтобы осветить, где люди могут ошибиться в скорости.

Традиционные базы данных могут быть очень быстрыми, если вы делаете для этого определенные специальные вещи, такие как игнорирование целостности данных или обработка их в другом месте. Вам не нужно ждать, пока жесткий диск очистит записи, вам не нужно навязывать отношения, вам не нужно навязывать уникальные ограничения, вам не нужно использовать транзакции, но если вы замените безопасность на скорость, то тебе нужно знать, что ты делаешь.

Решения NoSQL для сравнения, в первую очередь, как правило, предназначены для поддержки различных режимов масштабирования "из коробки". Производительность отдельного узла может быть не совсем такой, как вы ожидаете. Решения NoSQL также борются за общее использование со многими, имеющими довольно необычные характеристики производительности или ограниченные наборы функций.