Быстро выбирает / присоединяется к движкам хранения MySQL?

Question

У меня есть несколько очень больших баз данных (некоторые до 150M строк), с которыми я работаю и после первоначальной вставки данных не так уж много происходит INSERT's; просто много SELECT's и использование JOINS.

Я много возился с InfoBright (версия для сообщества), и хотя я считаю, что это хороший движок, лично у меня были некоторые проблемы с его настройкой, чтобы он работал так, как должен (быстро).

Так что мне было интересно, может ли кто-нибудь еще порекомендовать какой-нибудь другой быстрый бесплатный механизм хранения для MySQL?

Я только сейчас проверяю tokudb; есть ли что-нибудь еще, чтобы проверить?

Answer 1

Вы должны посмотреть на InfiniDB тоже. http://infinidb.org/ (один из самых быстрых)

Есть много соображений, которые вы должны сделать, прежде чем тестировать любой двигатель. Аппаратные средства, такие как многоядерные процессоры, память, конфигурация. Дизайн вещи, связанные с вашей схемой и т. Д. И т. Д. И как все это влияет на производительность двигателя.

Проверьте этот блог, как они проводят сравнительный анализ двигателей (он называет другие типы двигателей) - http://www.mysqlperformanceblog.com/2010/01/07/star-schema-bechmark-infobright-infinidb-and-luciddb/

Обратите внимание, что это сравнение относится к схеме звездообразной схемы. Если колоночный механизм БД не соответствует вашим требованиям, вы можете посмотреть XtraDB , который является расширенной версией InnoDB (не самой быстрой, но совместимой с ACID).

ps - всегда отслеживайте свойства (важные для вас) каждого механизма - такие как проверки ссылочной целостности, соответствие ACID и т. Д. Иногда эти ограничения могут быть более значительными, чем увеличение производительности запросов на 10%

Answer 2

Вы смотрели на Сфинкса вообще?Хотя это поисковая система, она также поддерживает поиск без запросов, что аналогично стандартным запросам SELECT с индексами.Я нашел, что это очень помогает при работе с большими наборами данных.Это очень быстро и активно используется на форумах с большим трафиком, которые занимают миллионы (или сотни миллионов) постов.

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

http://sphinxsearch.com/docs/2.0.1/sphinxse-overview.html (заметьте, у меня нет 'т очень много использовал до 1.0)

Answer 3

Помимо учета того, какую СУБД вы используете, вы должны также сосредоточиться на оптимизации ваших таблиц, индексов и запросов. Когда у вас есть несколько объединений, присоединяйтесь сначала к наиболее селективным отношениям, а затем к менее селективным. Проанализируйте ваши планы выполнения запросов. Создайте индексы для столбцов, которые часто попадают в ваши QEP.

Answer 4

Бретт - Используя Infobright, вы получаете максимальный прирост производительности за счет: 1) максимально возможного использования сетки знаний 2) уменьшения количества соединений 3) создания «поиска»

, поскольку сетка знаний находится в-память, вы можете убить много времени на запрос, просто добавив дополнительные фильтры.Кроме того, рассмотрите возможность использования вложенного выбора вместо объединения.Таким образом, вы можете использовать уже созданный узел знаний (вместо генерации узла «пакет-в-пакет» на лету).

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

Cheers,

Jeff