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

Question

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

Моя настройка состоит из следующего:

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

Я должен отметить, что парсер в настоящее время может анализировать / обрабатывать около 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 тысяч раз (на пользователя), так как они отключены от другого стола. Излишне говорить, что пока мы разбиваем эти результаты на 10 страниц.

Я посмотрел на следующее: (при условии, что они все на одном сервере)

• mysql (рег. Пробежки мельницы rdbms) - смог достичь диапазона 15-20 тысяч запросов / секунду; в текущих условиях, если мы пытаемся масштабировать это, нам нужен отдельный хост / база данных каждый раз, когда нам нужно масштабировать - это невозможно сделать

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

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

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

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

возможно, я просто неправильно подхожу к этой проблеме, но я ВСЕГДА слышал, что RDBMS были такими же медленными, как и все, черт возьми, - так где эти сверхбыстрые системы, о которых я слышал?

Условия испытаний ::

Просто чтобы люди знали, что мои спецификации на моей коробке разработчика:

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 ::

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

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

Answer 1

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

• Sharding: разделите ваш набор данных на группы, которые не пересекаются. Иметь простой и быстрый способ сопоставления запроса с сервером. (Игрок, начинающийся с a-f, сервер 1; g-q, сервер 2 ... и т. Д.) *
• Кэширование: используйте Memcache, чтобы запомнить результаты некоторых действительно распространенных запросов select, чтобы вам не приходилось часто заходить на диск.

Answer 2

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

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

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

Answer 3

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

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

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

Вы также пытались использовать SSD?

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

Answer 4

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

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

Также: MongoDB потрясающий. Может стоит посмотреть.

Answer 5

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

Answer 6

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

Answer 7

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

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

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

И да, CouchDB неутешительно медленен.

Answer 8

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

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