LINUX.ORG.RU

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

MrClon ★★★★★ ()

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

ggrn ★★★★★ ()

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

umren ★★★★★ ()

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

Legioner ★★★★★ ()

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

AnDoR ★★★★★ ()

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

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

BaBL ★★★★★ ()

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

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

no-such-file ★★★★★ ()

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

grondek ()

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

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

stevejobs ★★★★☆ ()
Ответ на: комментарий от stevejobs

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

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

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

Deleted ()
Ответ на: комментарий от BaBL

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

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



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

KRoN73 ★★★★★ ()

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

Iron_Bug ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

BaBL ★★★★★ ()
Ответ на: комментарий от Iron_Bug

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

Qwentor ★★★★★ ()
Ответ на: комментарий от Qwentor

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

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

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

ukr_unix_user ★★★★ ()
Ответ на: комментарий от Qwentor

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

ukr_unix_user ★★★★ ()

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

menangen ★★★★★ ()
Ответ на: комментарий от BaBL

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

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

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

Qwentor ★★★★★ ()
Ответ на: комментарий от Qwentor

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

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

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

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

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

BaBL ★★★★★ ()
17 сентября 2017 г.
Ответ на: комментарий от stevejobs

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

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

ism ★★★ ()
Последнее исправление: ism (всего исправлений: 3)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.