SQLite

Язык то хоть какой? Java? Еще leveldb есть. Под Java тоже есть.

firebird, вроде, умеет

У него, насколько я понимаю, плохо с производительностью при одновременной записи из нескольких приложений

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

Не, нафиг.. Особенно эта их идея открывать файл в начале транзакции и закрывать в конце. Для хранения букмарков в бровзере подойдет, для hiload нет

LevelDB побыстрее будет :) Но проект молодой, так что на свой страх и риск. Оно NoSQL и кроме как вытащить данные по ключу больше ничего и не может. LevelDB используется в Chrome для хранения IndexedDB.

Оно NoSQL и кроме как вытащить данные по ключу больше ничего и не может.

Ещё:

• атомарное применение серии операций записи
• может делать снапшоты состояния на чтение

NoSQL не надо. Слишком много будет проблем с переносом. Проще самим что-то в памяти написать

По идее со SQLite вообще нельзя работать из нескольких приложений, но я не проверял.

Читать из нескольких процессов - можно. Писать - нет.

Особенно эта их идея открывать файл в начале транзакции и закрывать в конце.

Разве это так в WAL-режиме?

Я к тому что LevelDB не умеет искать данные (нельзя писать запросы). Извлекать можно только по ключу.

Извлекать можно только по ключу.

А NoSQL подразумевает имеено такой подход, как я понимаю. Или нет?

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

NoSQL не надо.

Зачем двойное отрицание?

Проще самим что-то в памяти написать

есть риск вляпаться в черезмерное потребление памяти.
а потом придётся думать «а может всё таки sqlite и кэширование?»...

Нет, NoSQL это всё что не РСУБД. Там такой зоопарк что ой. Хранилища типа ключ-значение это всего-лишь частный случай.

Для этого нужна реляционная алгебра?
Раз уж дело дошло до оптимизаций вроде «unix-сокет это слишком медленно» и выбора под это СУБД... Советую получше осмотреться в отрасли, вы явно плаваете в том что выходит за пределы мира РСУБД.

Я к тому что LevelDB не умеет искать данные (нельзя писать запросы). Извлекать можно только по ключу.

Можно получить курсор на первую запись с ключом >= заданного и вытаскивать пока не надоест. При специально сформированном ключе это покрывает потребность в поиске в некоторой степени.

БЫСТРОЕ

NoSQL не надо!

Опять передозировка упорина?

дополнение ТС-у

Но если очень надо качественно упороться — Oracle так умеет.

А NoSQL подразумевает имеено такой подход, как я понимаю. Или нет?

Нет. Вот хорошая статья по CouchDB: http://guide.couchdb.org/draft/cookbook.html Запросы можно делать не хуже чем в SQL. В Монге тоже всяко-разно можно запросы делать.

У нас и так много чего написано. Очереди всякие. Есть и простейшие хранилища информации.

:).

А это не ключ. Это вторичный индекс. При этом это поле может периодически меняться.

Пример быстрого SQL - TimesTen. Очень мало NoSql будет его быстрее

если не сравнивать тёплое с мягким...

... т.е. данные в принципе не нужны, то таки почти все будут быстрее.

Не пробовали выражаться яснее? Я вас не понял.

В смысле, те NoSQL, которые умеют полностью in-memory

TimesTen хранит данные и на диске. И какой NoSql подходит под требования? Еще чтобы он был не страшным тормозом

Транзакции не синхронизируются. Это значит, что данные пользователю не нужны.

Критерии тормоза? Сколько нужно в граммах?

Как так не синхронизируются? Откуда вы это взяли. Тормоза - начнем с времени выборки и записи одной строчки по первичному ключу.

db2

Вы издеваетесь или не понимаете о чём пишете? Для «строчек» (в пределах пары килобайт) и то, и другое занимает единицы микросекунд. Мерять точнее не вижу смысла.

Т.е. вы утверждаете, что «select 1 from dual» на TimesTen и например на Postgresql займет одинаковое время?

(:

Содержательно пообщались.

Мде. Похоже надо подождать пока вы пройдёте детоксикацию...

1. Мы обсуждаем быстрый in-memory sql vs nosql. Казалось бы, причём здесь postgres?

2. Кому нужен select 1 from dual?

Ну мне, что доказывать, что есть опыт не только в области RDBMS?

Информация имеющаяся у меня на данный момент говорит как-раз о том что в области NoSQL вы таки плаваете.
Так-что, да.

Вообще я начал с того, что хочу быстрый SQL с драйверами через SHM. У меня обычно простые запросы, выполнятся они быстро. Если мерять время выполения запроса, то оно сложится из затрат на передачу запроса и его результата + само выполение запроса в базе данных. Выполняя select 1 мы замеряем первую часть этой суммы. Если она большая, то как ты не уменьшай вторую, сумма сильно не уменьшится. Т.е. можно там обобтимизироваться базу, но если драйвер говно - ничего не поможет.

Да, в области NoSQL я плавую. Но пока у меня нет задачи под NoSql. УЖЕ имеется приложение, которое умеет работать с Postgresql & TimesTen. Хотелось бы попробовать еще какую-то базу. Делать в одном приложении поддержу SQL & NoSQL ОДНОВРЕМЕННО на мой взгляд - перебор. Поэтом NoSQL пока особо не рассматривается.

Вы хотите заменить СУБД или добавить ещё одну?
Вообще одновременно использовать РСУБД и какую-нибудь nosql-ину очень даже православно. В общем-то все эти экзотические СУБД и нужны для того что-бы закрывать те места в которых РСУБД уже справляются или просто не очень подходят.
Классический, вырожденный, случай. Связка php+mysql+memcached.

Мы хотим добавить еще одну как выбор. Т.е. либо одна, либо вторая. У нас также есть хранение данных в SHM. Критичной явлется высокая производительнсть и быстрое время ответа. Пример приложения тут - freepcrf.com

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

затрат на передачу запроса и его результата

Если это — ключевой параметр, то выход один — засунуть базу в адресное пространство процесса.

Но я предпочитаю платить не только за BSD-сокет, но и за Ethernet чтобы иметь возможность масштабирования. 1млн запросов/сек (с учётом pipelining-а) с фронтенда меня вполне устраивают. Больше врядли понадобится.

Вот тестик сделал. Табличка из двух int32 колонок. Для TT делал 5 000 000 операций для PG 500 000. В результате цифры это CPS.

test      | Timesten | Postgresql |  Delta
insert    |    77811 |       7357 |  10.6x
select    |   179790 |       8734 |  20.5x
update    |    66604 |       6446 |  10.3x

Видно, что на самой простейшей операции - PG проигрывает в 20 раз.

Я правильно понимаю, что postgres потянул около 1k запросов/сек, а timesten — 10-20k? Это — детский сад. Если брать in-memory key-value хранилища, то redis отдаёт 50k одним ядром (как показывает практика, среднестатистический крестовый погромист не способен нагрузить его даже в такой конфигурации), и это через TCP over Ethernet. На 10Gb-интерфейсе упирается в драйвер сетевой карты (как я уже говорил, локальные сокеты не использую по причине трудностей с масштабированием). С использованием pipelining-а ограничений, можно сказать, нет (если не заниматься тупым перекачиванием байт с места на место).

Кастомное хранилище (держит «БД» в своём адресном пространстве), которое пришлось написать в виду сложностей распараллеливания, кушает 1млн update-ов/сек (в байтах это будет на гигабитный линк под завязку) + делает необходимые вычисления. Да, тоже одним ядром; и его ещё можно причесать (написал на коленке за пару дней), но лень.

Вы (видимо, из-за недостатка опыта) фокусируетесь не на том параметре. Latency достаточно good-enough, а вот throughoutput и особенно scalability — действительно важные фокусы.

Неправильно. Умножь на 10. т.е. Timesten 180k селектов а PG 8.7k в секунду. И это просто один поток на моем ноутбуке. Т.е. одно ядро. Т.е. еще должно масштабироваться на количество ядер. Если редис отдает 50к - то это детский сад.. Масштабирование у меня делается по другому. Мне проще поставить несколько инстансов и раскидать нагрузку между ними. Лоадбалансер уже нами написан. У меня время ответа сервера около 2 мс. И это важный, в том числе маркетинговый, показатель.

Мне проще поставить несколько инстансов и раскидать нагрузку между ними.

Дык вот здесь всю разницу съест сетевой стек + физический уровень. Вопрос: зачем корячиться с IPC?

Лоадбалансер уже нами написан.

На таких скоростях он первым и лопнет. Только разбрасывать DNS-ом.

У меня время ответа сервера около 2 мс. И это важный, в том числе маркетинговый, показатель.

Время абсолютно обычное. Даже в локальной сети разницу между 2мс и 5мс заметят только роботы.

У нас на не простой лоадбалансер. Он умеет HTTP & DIAMETER. Там вообще все непросто. Он умеет пропускать через себя приблизительно 100к запросов и ответов по DIAMETER в секунду на стандартном сервере. Вот в нем как раз самописная база в SHM для хранения сессий. Там еще приходится иногда менять пропущенные через себя пакеты. Каждый запрос по DIAMETER приводит к куче запросов к базе данных. Поэтому нагрузка на балансер не такая высокая как на базу. Мы с роботами и работаем. Если инетесно, то например наша система работет в yota. Именно наши сервера управляют шейпингом, турбокнопками итд.