Битва key-value хранилищ
Какие key-value хранилища вы используете в бою? Позаимствовал список с сайта db-engines.com (кстати очень любопытный сайт, рекомендую), включил все базы с ненулевой «популярностью» оттуда. Не отмечайте базы которые просто пробовали/интересно, а только те, что крутятся и приносят деньги вашей компании прямо сейчас.Обратите внимание: MongoDB это НЕ key-value хранилище, однако за нее можно проголосовать, см. 4 снизу пункт.
Пишите, если забыл какую-то популярную базу (т. е. забыли авторы сайта db-engines.com), добавлю в опрос.
Какие свойства key-value хранилища вам важны? Разношерстная куча требований. Просьба вдумчиво пройтись по ним. Обратите внимание, что многие свойства противоречат друг другу, потому что половина направлена на функциональность, а другая — на производительность, которые в целом противоречат друг другу. Некоторые свойства возможны только при наличии других свойств или комбинаций, некоторые являются усиленными/ослабленными версиями друг друга, и т. д. Пункты 2–6 описывают какие-то разумные свойства транзакций (кстати, вам могут быть вообще не нужны транзакции: (напр. простые get и put по ключу — это еще не транзакции), тогда не отмечайте ни один из этих пунктов), пункты 7–9 — уровень согласованности свойств, указанных выше.
«Нативный клиент для Java/С/С++/С#» — значит клиент для этих языков не просто формирует запрос на языке, на котором написана база, и идет в какой-нибудь IPC/JNI, а прямо работает с базой. По сути, это означает, что база написана (в том числе) на этом языке. Благодаря наличию таких штук, как Protocol Buffers, Thrift и подробных, база, вообще говоря, может быть написана на нескольких языках.
Я 100% забыл какие-то важные свойства, пишите в личку, добавлю в опрос.
Какие свойства key-value хранилища вам важны?
Масштабируемость (хочу хранить больше / выдерживать большую нагрузку добавлением серверов) Атомарность транзакций по одному ключу (либо записать вcе изменения значения, либо ничего) Изолированность транзакций по одному ключу (несколько одновременных транзакций по одному ключу запрещены) Надежность (durability) транзакций (после окончания транзакции я точно не потеряю данные) Атомарность транзакций по нескольким ключам Изолированность транзакций по нескольким ключам (несколько одновременных транзакций, пересекающиеся по ключам, запрещены) Транзакции в пределах сервера (на ДЦ/всю базу изменения распространятся со временем) Транзакции в пределах ДЦ (на всю базу изменения распространятся со временем) Транзакции на всю базу Отказоустойчивость (сгорел сервер — продолжаем работу) Крутая отказоустойчивость (отключился ДЦ — продолжаем работу) Репликация изменений между серверами (свойство чуть слабее, чем масштабируемость) Упорядоченность по ключам (возможность итерироваться по ключам в отсортированном порядке, найти ближайший больший/меньший, чем данный, ключ, и т. д.) Гарантии максимального времени ответа (response latency) Подписка на события по ключу Логгирование (какое-нибудь, как минимум хочу иметь возможность видеть, что происходит с базой, для дебага) Логгирование изменений с возможностью воспроизведения Асинхронное API (получил future по ключу) Хранение данных в памяти (ходить за каждым ключом на диск — слишком медленно) Хранение на диске (напр. для надежности, если БД не распределенная) Поддержка Windows (хочу гонять базу на своей девелоперской Винде / у меня Windows сервера) Поддержка MacOS (хочу гонять базу на своем девелоперском Маке) Удаленные запросы (RPC, тонкие клиенты) Нативный клиент для Java Нативный клиент для С/С++ Нативный клиент для С# Веб-интерфейс (слать CRUD запросы по HTTP) Веб-морда для мониторинга базы Бекап в реляционную БД Какой-нибудь бекап Не нужны никакие свойства, как и key-value хранилища в принципе Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Проголосовало 97 человек. Воздержалось 153 человека.
