Существуют ли СУБД, позволяющие делать insert порядка 50 000 раз в секунду, хотя бы локально?

Интересует именно реальная запись на диск, а не в буфер нескольких десятков тысяч записей в секунду. Если просто писать в двоичный или текстовый файл записи такого же размера, то получается примерно 50-60 тыс в сек на sata винте. Ни Interbase ни MySQL даже близко к такой производительности не подбирается.

А Cache точно коммитит миллион записей в секунду?! Или там отложенная запись работает?

DPHА что именно нужно записывать, какие именно insert, есть ли дополнительные требования, пиковая нагрузка или нет?

Про 1E6 в секунду на Cache - это, конечно, фигня, просто по скорости железа не проходим... Скорее всего считалось время с учетом кэша операционной системы или рейда. Ну и без транзакций, конечно.

insert коротких записей: одно-два целочисленных поля, одно-два вещественных и короткая строка байт на 20, т.е. размер одной записи около 50 байт.

20-30 000 в сек - такая нагрузка нужна постоянно, временную пиковую, за миллион, можно за счет буферизированной отложенной записи добиться.

Вообщем, после долгих экспериментов оказалось, что SQLite все-таки может давать такую скорость, однако, далеко не с каждой библиотекой доступа.

kdv AAronпотому что разный опыт. одно дело крутить firebird на рабочей станции, другое - Oracle/DB2/SQL Server на машине за 500К+ вечнозеленых.
если это намек на чужой опыт, то не надо грязи. К тому же, тут FB никто не предлагал.
человеку пытаются объяснить, что
1. для 50к сек как минимум нужны соответствующие диски (железо)
2. для обработки данных такого объема нужна соответствующая, и возможно специфическая СУБД.

GoodkatВообщем, после долгих экспериментов оказалось, что SQLite все-таки может давать такую скорость
вы лучше подумайте или объясните, что вы с накопленными данными будете делать. Залить-то можно, вопрос в том, зачем оно нужно, залитое. Например, если посчитать среднее за день, то запросу придется перелопачивать 80 гиг. Сколько времени это будет делать SQLLite? Куда вы будете девать накопленные данные через год, которых накопится под 30 терабайт?
Я не говорю, что систему под такую задачу нельзя построить. Можно. Только если ее строить "в лоб", с такими объемами она работать не будет.

Разумеется все данные не будут лежать в одной базе - будет разбиение на файлы по 100-500 Мб. Перед непосредственным SQL запросом на чтение нужные файлы отбираются по дополнительной информации (есть промежуточный сервер доступа).

По поводу общего объема - вероятно все-таки скорость в 40К в сек не постоянна (но все-таки значительно больше того времени, когда можно было бы обойтись только буферизацией).

barrabas GoodkatВообщем, после долгих экспериментов оказалось, что SQLite все-таки может давать такую скорость, однако, далеко не с каждой библиотекой доступа.
так она вроде блокирует целиком таблицу, если ты будешь один перманентно только писать туда то фиг с ней, а если еще в это время и читать то ёк

Да есть такая гадость, но особенность задачи такая, что запросов на чтение очень мало и они не особо критичны по времени исполнения (в разумных пределах), тем более что, как правило, запросы будут к более старым данным, т.е. к базам уже закрытым на запись.

VoDA kdvне давайте автору топика ложных надежд. скорость вставки - это малая часть задачи. Да, конечно, с такой скоростью вставки справятся большинство серверов. И SQLLite, и MySQL, и Firebird, и PostgreSQL. Весь вопрос в том, что будет когда через месяц в этой системе будет накоплено 2.5 терабайт данных. А также в том, что еще кроме вставки предполагается делать с данными (в том числе во время вставки).
Думаю, никто не будет спорить, что упомянутые мной здесь 4 сервера не способны нормально работать с такими объемами. То есть, залить такой объем в них наверняка можно, но вот дальше...и MySQL, и PostgreSQL - работать смогут (по заявлениям с сайтов производителей ))) )
А что такое нормально - это еще вопрос. ИМХО с любой БД больше 10 Gb нужно уметь правильно готовить.

А вот из MySQL я больше 4000 в сек выжать не смог :( Из Firebird и того меньше.
Может кто подскажет как?