(Как может/что должен) Я реализую базу данных, которая масштабируется до верхних десятков тысяч запросов в секунду?

Question

К верхним десяткам тысяч запросов в секунду Я хочу видеть 60 000 -> +90 000 запросов в секунду.

My Setup состоит из следующих действий:

пользователя ---> Веб-приложение -> Очередь сообщений -> анализатор -> базы данных?

Следует отметить, что в настоящее время анализатор может анализировать/обрабатывать около 18750 записей в секунду с использованием COPY, поэтому мы ограничены в этом направлении, пока не начнем добавлять больше парсеров - сейчас это не вызывает большого беспокойства.

У меня есть система, которая требует возможности массовой загрузки так же быстро, как я могу, сколько записей. Эта же система (или она может быть разной в зависимости от того, как вы приближаетесь к нему) должен быть в состоянии реагировать на запросы аналитических типов, таких как это:

 
wonq = "select sum(amount) from actions where player = '@player' and " + 
     "(type = 'award' or type = 'return') and hand = hand_num" 
lostq = "select sum(amount) from actions where player = 'player' and " + 
     "type != 'award' and type != 'return' and hand = hand_num" 

..... 10-15 тысяч раз (PER USER), поскольку они привязаны к другой таблице. Излишне говорить, что мы сейчас разбиваем эти результаты на 10/страницу.

Я посмотрел на следующее: (. Рег заурядным РСУБД) (предполагается, что они находятся на том же сервере)

• MySQL - смог попасть в 15-20 тыс. запросов/второй диапазон; в нынешних условиях, если мы попытаемся это масштабировать, нам нужен отдельный хост/база данных каждый раз, когда нам нужно масштабировать - это не выполнимо

• couchdb (document oriented db) - не сломал 700 запросов/секунду; Я действительно надеялся, что это спасет нашу задницу - не случайность!

• vertica (columnar oriented db) - ударил 60000 запрос/секунду, закрытый источник, очень дорогой; это все еще вариант, но мне лично это совсем не понравилось

• tokyocabinet (hash based db) - в настоящее время весит 45 000 вставок в секунду и 66 000 выборок в секунду; вчера, когда я написал это, я использовал адаптор FFI, который выполнял около 5555 запросов в секунду; это на сегодняшний день самая быстрая самая удивительная база данных, которую я видел еще!

• terracotta - (vm cluster) в настоящее время оценивает это вместе с jmaglev (не могу дождаться, пока сам маглев не выйдет) - это МЕДЛЕННО!

может быть, я просто приближаюсь эта проблема неправильно, но я всегда слышал, что RDBMS медленно, как весь ад - так где эти супер быстрые системы, которые я слышал о?

Условие тестирования ::

Просто так госзакупки знают мои спецификации на моем Dev окне:

 
dual 3.2ghz intel, 1 gig ram 

Mysql MySQL.CNF редактирует были:

 
key_buffer = 400M    # was 16M 
innodb_log_file_size = 100M  # non existent before 
innodb_buffer_pool_size = 200M # non existent before 

UPDATE ::

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

С другой стороны, я был очень рад видеть, что библиотека ruby-библиотеки tokyocabinet NON-FFI (что означает тиран/кабинет) является супер быстрой и прямо сейчас, что является первым местом.

Answer 1

Для безумном-большой масштабируемости, вы хотите, чтобы сосредоточиться на двух вещах:

• шардинге: Разделите набор данных на группы, которые не перекрывают друг друга. Простой и быстрый способ сопоставления с запросом на сервер. (Player, начинающийся с af, server 1; gq, server 2 ... и т. Д.)
• Кэширование: используйте Memcache, чтобы запомнить вывод некоторых действительно распространенных запросов выбора, поэтому вам не нужно идти на диск как довольно часто.

Answer 2

Ну, большой игрок в игре - это Oracle, но это большие деньги.

Если вы хотите идти дешево, то вам придется заплатить цену в различных условиях:

• по partioning БД в нескольких экземплярах и распределения нагрузки.
• Потенциально кэширующие результаты, поэтому фактический доступ к БД уменьшается.

Answer 3

пользователь ---> веб-приложение -> очередь сообщений -> парсер -> база данных?

Для чего нужна очередь сообщений? Это большая проблема с производительностью.

Answer 4

Осколок и кеширование, как сказал ойрак.

Другой вариант - сделать шаг назад и выяснить, как работать с меньшим количеством запросов! Из небольшой информации, которую вы дали, я не могу не думать «должен быть лучший способ». Из примеров, которые вы давали некоторые сводные таблицы (с дополнительным кэшированием), может быть легко победить.

Hypertable и т. Д. Дает лучшую производительность для некоторых моделей доступа к данным, но ваш звук очень подходит для типичных баз данных.

И да, CouchDB разочаровывает медленно.

Answer 5

Вы пробовали postgresql? он должен быть быстрее, чем mysql. но в любом случае вам нужно будет сбалансировать нагрузку на несколько серверов (сплит-база данных). вы можете иметь несколько баз данных (например, для каждого клиента), а затем один централизованный, который будет синхронизироваться с этими маленькими ...

Answer 6

Вы пробовали redis? Они обещают скорость 110000 SETs/second, 81000 GET/секунду. Это расширенный ключ-значение db с поддержкой списков и наборов.

Answer 7

Я сомневаюсь, что любая система предоставит вам готовые результаты, которые вам нужны. Вероятно, вы начнете сталкиваться с жесткими ограничениями на машине, на которой вы находитесь (с почти любой интенсивной записью db вы быстро достигнете пределов ввода-вывода).Может потребоваться некоторый анализ, но диск почти всегда является узким местом. Больше оперативной памяти поможет, как и использование твердотельных дисков.

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

Также: MongoDB является удивительным. Возможно, стоит посмотреть.

Answer 8

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

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

Существует механизм хранения mysql, который делает это, вы хотите использовать mysql. Другой вариант - одна из новых баз данных nosql, таких как fleetdb.

Вы пробовали использовать SSD?

Существует множество вариантов решения этой проблемы, но они, вероятно, потребуют ручного труда.