Какая БД наиболее производительна с точки зрения операций INSERT?

Для мускуля есть какой-то специальный движок заточеный на инсерты. Не помню название. В MariaDB его в стандартную поставку включили.

а тебе прям вот обязательно раз в секунду писать? а набирать и записывать стопкой никак?

бд на основе /dev/null

Любая бд сможет намного больше. Бери постгрес.

Любая современная субд умеет и больше, но ты бери постгрес.

Сабж. Нужно чтоб могло в десятки, а лучше больше операций INSERT в секунду.

Тебе подойдет AppendFile на любом языке. В зависимости от хардов может позволять тысячи и тысячи инсертов в секунду.

Нужно чтоб могло в десятки, а лучше больше операций INSERT в секунду.

Для Б3-38 пишешь что ль?

Десятки INSERT это очень небольшая нагрузка. Бери Постгрес.

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

А вообще, зависит от объема данных и архитектуры

Например, если поставить Apache Ignite перед какой-нибудь быстрой БД (Mongo, Couchbase, или какая-нибудь современная RDBMS типа Oracle) для persistent store, и воткнуть на сервер побольше оперативки, да еще и будешь класть тупо putIfAbsent, то оно выдаст тебе совсем фантастический перфоманс

десятки, а лучше больше операций INSERT в секунду

поставить Apache Ignite перед какой-нибудь быстрой БД (Mongo, Couchbase, или какая-нибудь современная RDBMS типа Oracle) для persistent store, и воткнуть на сервер побольше оперативки

Отлично, например

Тебе подойдет AppendFile на любом языке. В зависимости от хардов может позволять тысячи и тысячи инсертов в секунду.

А теперь ставим эти инсеты параллельно, с залочкой файла. На фрагментированный HDD. И в количестве хотя бы 100 тыс. штук по 100 байт (10Мбайт, внезапно) и твой AppendFile превращается в тыкву.

…

Я с таким с большим удивлением столкнулся ещё в 2000-м. До этого тоже наивно считал, что простые файлы быстрее сложных БД :D

Cassandra

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

Я с таким с большим удивлением столкнулся ещё в 2000-м. До этого тоже наивно считал, что простые файлы быстрее сложных БД :D

Я не считаю что файлы лучше больших СУБД, я считаю что ТС очень несостоятельное ТЗ выдал и ждет советов.

Ему сейчас насоветуют БД для инсертов, в которой он не сможет сделать потом нужный ему Select.

Да, десятки (лучше более 100 конечно) это в одну таблицу. Таблиц будет штук 30 точно. Писать постоянно и без остановки. Устаревшие данные удалять, чтоб не росло терабайтами, ну например по дате.
В 1 таблицу будет писать 1 клиент.

SELECTы тоже важны не менее, в общем-то

Устаревшие данные удалять

delete-ом наверное собираешься удалять?

с такой постановкой вопроса ваш проэкт обречён на провал. вносите ДБА в бюджет.

Можно не делитом, а таблицы по дням сделать

да, а теперь представь что нужно сделать запрос за больше чем один день, за неделю например или за год.

Даже SQlite легко справится на SSD с такой задачей.

Можно не делитом, а таблицы по дням сделать

Найдите себе DBA

можешь взять постгрес, но все знают, что bdb рулит и педалит

а вообще, кто за тебя гуглить будет?

http://highscalability.com/blog/2012/11/29/performance-data-for-leveldb-berkl...

Найдите себе DBA

может быть.. внесу на рассмотрение)

но все равно хотелось бы чтоб посылали конкретнее - где и что читать, а не только найдите DBA

но все равно хотелось бы чтоб посылали конкретнее - где и что читать, а не только найдите DBA

Что почитать:
Database Administration книги по всем современным СУБД.

Пройти курсы DBA для начинающих, потом курсы DBA Advanced.

Понять что ответа на твой вопрос нету в 2 строчки и это большая комплексная работа. Если не хочешь ею заниматься - бери любую СУБД, дельного с таким подходом тебе никто не посоветует ничего.

Дальше 3 варианта:
1. Проект говно, умрет сам, еще до начала проблем с БД
2. Проект ниче так, но явно не сильно зависящий от ресурсов БД, будет жить на чем угодно и проблема явно преувеличена.
3. Проект будет на грани краха в самый неподходящий момент, вы все равно обратитесь к DBA, но получите больше геммороя, нервов и потратите существенно больше денег, чем приняв это решение сейчас.

/dev/null, конечно же

В mariadb есть еще aria движок, он очень быстр в НЕ транзакционном режиме

А так если инсертить внутри транзакции, то innodb вполне быстр

Всего 15 месяцев прошло, зачем такая поспешность с ответом?

Анабиоз, сэр.

ПС: а firebird почему-то никто не вспомнил…

Ещё для событий/логов крутая штука: http://traildb.io