выбор базы данных

Не бывает. Забей. Заюзай блобохранилище в SQL. Хипстеров — на метан.

/thread

Есть в принципе форк монги, http://www.tokutek.com/products/tokumx-for-mongodb/

Не без своих косяков (особенно в плане совеместимости с монгой) но врое работает.

Но ее нет под винду к сожалению.

А так в принципе, поддерживаю предыдущего оратора, вполне можно забить на nosql, а банально взять постгрес. Если нормально спроектировать базу и не налегать на join-ы в частых запросах - проблем с производительностью не будет. Да и json/bson/xml поля никто не мешает использовать для данных с гибкой схемой.

Посмотри http://docs.couchbase.com/

Правда транзакции там такие: http://docs.couchbase.com/couchbase-manual-2.5/cb-admin/#couchbase-views-samp...

nosql

sql! все included.

PostgreSQL.

транзакции
журналирование
быстрое чтение
неблокирующая заись

WAL и MVCC покрывают эти пункты.

подписка на изменения (желательно)

Есть; раньше можно было использовать триггеры и listen/notify, в версии 9.4 есть подписка на изменения (как часть протокола репликации).

c api

Эм, а есть СУБД без API?

кроссплатформенность (linux, windows)

Таки да.

не in-memory (данных не больше 100 gb)

Kyoto Tycoon

Проще всё в один документ чаще запихнуть. Олсо были проблемы с java клиентами, но вполне оперативно фиксится.

почему не mmap-нуть файл и не разместить там Posix hashtable

orientdb

Любая популярная БД может быть как NoSQL. Некоторые из них даже специально заточены.

Эрланг имеет неплохие встроенные реализации хранилищ - практически все, по твоим требованиям есть, остальное можно допилить. Насчет производительности не знаю.

Одновременно транзакций и неблокирующей записи не бывает. Толку от таких транзакций? Представь из нескольких потоков в разных транзакциях делают: update mytable set counter = counter + 1. Если не блокировать то будет просто last write win с потерей части апдейтов. Если нужно много апдейтов, то бери cassandra.

Одновременно транзакций и неблокирующей записи не бывает. Толку от таких транзакций? Представь из нескольких потоков в разных транзакциях делают: update mytable set counter = counter + 1. Если не блокировать то будет просто last write win с потерей части апдейтов.

Путаешь уровни изоляции с блокировкой, это разные вещи.

Конечно разные. Но на практике я не встречал другого: все изестные мне реляционки блокируют или строку или таблицу на апдейт не зависимо от уровня изоляции.

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

?

http://en.wikipedia.org/wiki/Multiversion_concurrency_control - там внизу список реляционок которые не блокируют

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

Конечно разные. Но на практике я не встречал другого: все изестные мне реляционки блокируют или строку или таблицу на апдейт не зависимо от уровня изоляции.

В общем оно так и от этого нельзя избавиться, но область и кол-во блокировок при разных операциях может существенно варьироваться. Некоторые СУБД не могут даже инсерты делать без полной блокировки таблицы, какие-то стараются делать минимально необходимое кол-во локов. Блокирующими (всегда) обычно считают первый подход, самый тупой.

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

Угу, хотя я вот не очень понимаю почему нельзя лочить только столбцы, хотя бы. Известные мне реляционки лочат не меньше, чем строку.

Что касается неблокирующей записи, почему же, архитектура субд штука известная, можно и выбором базы решить.

Угу, хотя я вот не очень понимаю почему нельзя лочить только столбцы, хотя бы. Известные мне реляционки лочат не меньше, чем строку.

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

Можно делить таблицу на несколько по группам колонок и работать с ней через VIEW с JOINом на чтение + апдейты по отдельным таблицам. Будет умеренный гранулированный лок на группы столбцов.

Спасибо за разьяснение. Я так понимаю колоночные базы лишены такого недостатка?

Спасибо за разьяснение. Я так понимаю колоночные базы лишены такого недостатка?

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

Т.е. фактически да, недостатка такого у них нет, но не из-за того что его как решили, а в силу более топорной архитектуры и отказа от ACID в пользу менее строгих требований.

Должна выполняться в отдельном процессе (на отдельном устройстве)