LINUX.ORG.RU

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

 ,


0

2

Помогите, пожалуйста, подобрать базу данных по следующим требованиям:

  • транзакции
  • журналирование
  • быстрое чтение
  • неблокирующая заись
  • подписка на изменения (желательно)
  • c api
  • кроссплатформенность (linux, windows)
  • не in-memory (данных не больше 100 gb)

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

/thread

Macil ★★★★★ ()

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

Nagwal ★★★★ ()

PostgreSQL.

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

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

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

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

c api

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

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

Таки да.

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

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

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

anonymous ()

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

crowbar ()

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

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

swwwfactory ★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

mashina ★★★★★ ()

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

note173 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.