Вообщем расклад такой - таблица, в ней следующие поля - INT(11) INT(20) VARCHAR(6) VARCHAR(15).
В таблицу будет примерно 100-200 инсертов в секунду, и 5-10 селектов в секунду (селекты большие, до 10к строк). Нужна субд способная всё это переварить с минимальными затратами процессорного времени, и при этом иметь вменяемый размер бд . Записей в таблице будет несколько миллиардов . Пока что выбор пал на MongoDB, но уж очень прожорливый он что касается дискового пространства. Спасибо.

Евгений Мирошниченко aka mirПоскольку вас волнует только скорость вставки и размер БД, идеальный выбор для вас -- просто писать в файл. Наивысшая скорость и компактность.
А самое главное асинхронность, попробуйте одновременно со 100 клиентов писать в файл, что получите? Или пардон, их в очередь ставить как на почте России?:)

SiemarglWol_fiпропущено...

А самое главное асинхронность, попробуйте одновременно со 100 клиентов писать в файл, что получите? Или пардон, их в очередь ставить как на почте России?:)Есть стандартные приемы. Думаешь СУБД не в файл пишут, а параллелят запись с помощью святого духа? )))
Да вот только мне кажется, что у меня не получится решить вопрос очерёдности лучше чем у команды программистов любой СУБД.

Dimitry Sibiryakov
Зачем "фул"? Мой телепатер говорит, что аффтару нужны исключительно выборки класса "Х
последних записей".


Ваш телепатер барахлит, небось на aliexpress заказывали?:)

По поводу выборок - селекты могут быть как и по последним записям, так и WHERE `x`<10 AND `y`='blablabla' AND z>100

Чтобы было понятней - имеется api веб-ресурса с нагрузкой примерно 100-200 запросов в секунду, нужно записывать каждый запрос (ip, время, id-пользователя, etc), ну и далее уже из этих записей работать некоторым службам.

SERG1257Wol_fi По поводу выборок - селекты могут быть как и по последним записям, так и WHERE `x`<10 AND `y`='blablabla' AND z>100 То бишь инициатор выборок человек (не робот) и доступа к записям последней секунды не требуется.
Тогда самый простой путь: вебсервер кидает все запросы в журнал, который периодически оптом грузится в любую СУБД для анализа.
Хотя вам лично я посоветую другой путь: возьмите любую экзотическую базу и подробно напишите грабли на которые наступили.
Тоже подумал сначала в эту сторону, но сервис коммерческий, a заказчик не очень щедрый на железные ресурсы:) Каждый запрос тянет финансовую транзакцию, которая тянет статистику и биллинг, то есть данные могут понадобится real-time до секунды (пользователя запросил выплату, или статистику), и при этом весь этот механизм должен тянуть сервер Intel® Core™ i7-2600 quad core с 6тб дискового пространства и 16гб оперативки. Бекенд сервиса крутится на PHP и мускуле. Возможности все переписать с нуля на чём-то, что шустрее php - нет, взялся за недоделанную предыдущими исполнителями работу. Так вот смысл в том, что бекендом сервер и так постоянно нагружен, нужно вклинить в него при этом статистику, чтобы не слёг от перегруза. Понимаю что по нормальному, нужно отделить мух от котлет - бизнес-логику на один сервер, бд на другой, статистику на третий - но увы сервер тут один. Поэтому собственно и интересуюсь, какая субд справится с поставленной задачей с минимальным затратами ресурсов.

SERG1257Wol_fi какая субд справится с поставленной задачейMySQL ибо оно уже стоит. ЛЮБАЯ другая субд это риск.
Wol_fi данные могут понадобится real-time до секундыМогут или понадобятся решает заказчик и только он. Нормальный вменяемый пользователь поймет, если большими буквами будет написано что данные доступны только до последнего часа или минуты (минута уже достаточно хороший интервал буферизации)
Wol_fi Тоже подумал сначала в эту сторону, но сервис коммерческий, a заказчик не очень щедрый на железные ресурсы:)В отличии от переделок софта, затраты на железо гораздо надежнее. Вероятность поймать проблемы после установки нового сервера (процессора, памяти, диска) конечно же есть, но она не сравнима с вероятностью огрести после установки патча или новой субд. И если заказчик на это не идет ТО ЗАКАЗЧИКА ДАННАЯ ПРОБЛЕМА НЕ ТРОГАЕТ.
Признайтесь честно, вам захотелось потрогать этот MongoDB в условиях приближенных к боевым.
Тонко:)
Трогайте


Вы видимо работаете в параллельной вселенной. Так как в этой адекватный заказчик, понимающий все тонкости попадается редко. Это к сожалению не такой случай. А мускульные InnoDB и MyISAM очень частенько отказывают|ложатся при больших размерах, что в этом случае не очень хорошо.