БД с лучшими вставками / сек производительность?

Question

Мы развертываем (на основе AJAX) Мессенджер, который обслуживается сервером Comet. У нас есть требование хранить отправленные сообщения в БД для долгосрочного архивирования в целях соблюдения требований законного хранения.

Какой механизм БД обеспечивает наилучшую производительность в этом требовании однократной записи, без чтения (за редким исключением)?

Нам нужно не менее 5000 вставок / сек. Я не предполагаю ни MySQL, ни PostgreSQL может соответствовать этим требованиям.

Есть предложения по более высокопроизводительному решению? HamsterDB, SQLite, MongoDB ...?

Answer 1

Пожалуйста, не обращайте внимания на вышеуказанный бенчмарк, внутри которого была ошибка.

У нас есть записи Insert 1M со следующими столбцами: id (int), status (int), message (140 символов, random). Все тесты проводились с драйвером C ++ на настольном ПК i5 с диском Sata 500 ГБ.

Тест с MongoDB :

1M Вставка записей без индекса

time: 23s, insert/s: 43478

1M Вставка записей с индексом на Id

time: 50s, insert/s: 20000

затем мы добавляем 1M записей в ту же таблицу с индексом и 1M записей

time: 78s, insert/s: 12820

, что приводит к тому, что на fs почти 4Гб файлов.

Тест с MySQL :

1M Вставка записей без индекса

time: 49s, insert/s: 20408

1M Вставка записей с индексом

time: 56s, insert/s: 17857

затем мы добавляем 1M записей в ту же таблицу с индексом и 1M записей

time: 56s, insert/s: 17857

точно такая же производительность, без потерь на MySQL при росте

Мы видим, что Mongo съел около 384 МБ ОЗУ во время этого теста и загрузил 3 ядра процессора, MySQL был доволен 14 МБ и загрузил только 1 ядро.

Эдориан был на правильном пути со своим предложением, я сделаю еще несколько тестов, и я уверен, что мы можем достичь на 2x четырехъядерных серверах со скоростью 50 тыс. Вставок / сек.

Я думаю, что MySQL будет правильным решением.

Answer 2

Если вы никогда не собираетесь запрашивать данные, то я бы вообще не сохранял их в базе данных, вы никогда не снизили бы производительность, просто записав их в плоский файл.

Что вы могли быЯ хочу рассмотреть проблемы масштабирования, что происходит, когда происходит медленная запись данных в плоский файл, вы будете инвестировать в более быстрые диски или что-то еще.

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

edit: Вы написали, что хотите иметь его в базе данных, а затем я также рассмотрю проблемы безопасности сИмея данные в оперативном режиме, что происходит, когда ваша служба подвергается риску, хотите ли вы, чтобы ваши злоумышленники могли изменить историю сказанного?

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

Answer 3

Если вам не нужно делать запросы, тогда база данных - это не то, что вам нужно. Используйте файл журнала.

Answer 4

хранится только по юридическим причинам.

А как насчет подробных требований? Вы упомянули решения NoSQL, но они не могут обещать, что данные действительно хранятся на диске. В PostgreSQL все безопасно для транзакций, поэтому вы на 100% уверены, что данные находятся на диске и доступны. (только не включайте fsync)

Скорость во многом зависит от вашего оборудования, вашей конфигурации и вашего приложения. PostgreSQL может вставлять тысячи записей в секунду на хорошем оборудовании и при использовании правильной конфигурации, он может быть мучительно медленным при использовании того же оборудования, но при использовании простой глупой конфигурации и / или неправильного подхода в вашем приложении. Один INSERT медленный, многие INSERT в одной транзакции намного быстрее, подготовленные операторы еще быстрее, а COPY творит чудеса, когда вам нужна скорость. Вам решать.

Answer 5

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

Answer 6

Firebird может легко обрабатывать 5000 вставок / сек, если таблица не имеет индексов.

Answer 7

В зависимости от настроек вашей системы MySql может легко обрабатывать более 50 000 вставок в секунду.

Для тестов в текущей системе, над которой я работаю, мы получили более 200 тыс. Вставок в секунду. с 100 одновременными подключениями к 10 таблицам (только некоторые значения).

Не говоря уже о том, что это лучший выбор, поскольку другие системы, такие как couch, могли бы упростить репликацию / резервное копирование / масштабирование, но отказались от mysql исключительно из-за того, что он не может обрабатывать такие незначительные объемы данных, которые немного грубоваты. *

Я полагаю, что есть лучшие решения (читай: дешевле, проще в управлении).

Answer 8

Я полагаю, что ответ также будет зависеть от типа жесткого диска (SSD или нет), а также от размера вставляемых данных. Я вставлял данные одного поля в MongoDB на двухъядерной машине с Ubuntu и выполнял более 100 записей в секунду. Я ввел в поле некоторые довольно большие данные, и они упали примерно до 9ps, а процессор работал примерно на 175%! В коробке нет SSD, и поэтому я бы хотел узнать, поправился бы я с этим.

Я также запустил MySQL, и мне потребовалось 50 секунд, чтобы просто вставить 50 записей в таблицу с 20-миллионными записями (с примерно 4 приличными индексами тоже), так что с MySQL это будет зависеть от того, сколько индексов у вас есть. 1003 *

Answer 9

Я бы использовал для этого файл журнала, но если вам нужно использовать базу данных, я настоятельно рекомендую Firebird . Я только что проверил скорость, она вставляет около 10 тыс. Записей в секунду на довольно среднем оборудовании (настольный компьютер 3 года). Таблица имеет один составной индекс, поэтому я думаю, что без него он работал бы еще быстрее:

milanb@kiklop:~$ fbexport -i -d test -f test.fbx -v table1 -p **
Connecting to: 'LOCALHOST'...Connected.
Creating and starting transaction...Done.
Create statement...Done.
Doing verbatim import of table: TABLE1
Importing data...
SQL: INSERT INTO TABLE1 (AKCIJA,DATUM,KORISNIK,PK,TABELA)  VALUES (?,?,?,?,?)
Prepare statement...Done.
Checkpoint at: 1000 lines.
Checkpoint at: 2000 lines.
Checkpoint at: 3000 lines.
...etc.
Checkpoint at: 20000 lines.
Checkpoint at: 21000 lines.
Checkpoint at: 22000 lines.

Start   : Thu Aug 19 10:43:12 2010
End     : Thu Aug 19 10:43:14 2010
Elapsed : 2 seconds.
22264 rows imported from test.fbx.

Firebird с открытым исходным кодом и совершенно бесплатно даже для коммерческих проектов.

Answer 10

Если деньги не играют роли, вы можете использовать TimesTen.http://www.oracle.com/timesten/index.html

Полная база данных в памяти с потрясающей скоростью.