Какие хранилища «ключ-значение» вы используете в бою? Список взял с сайта db-engines.com (кстати, очень интересный сайт, рекомендую), все базы с ненулевой «популярностью» я включил оттуда.
Не отмечайте базы, которые вы только что попробовали/интересны, а только те, которые крутятся и приносят деньги вашей компании прямо сейчас.
Обратите внимание: MongoDB НЕ является хранилищем «ключ-значение», но вы можете проголосовать за него, см.
«Хранилище документов как ключ-значение».
Пишите, если вы забыли какую-то популярную базу данных (то есть забыли авторы сайта db-engines.com), я добавлю ее в опрос.
Какие свойства хранилища «ключ-значение» важны для вас?
Пестрая куча требований.Пожалуйста, просмотрите их вдумчиво.
Обратите внимание, что многие свойства конфликтуют друг с другом, поскольку половина ориентирована на функциональность, а другая на производительность, что обычно противоречит друг другу.
Некоторые свойства возможны только при наличии других свойств или комбинаций, некоторые являются более сильными/слабыми версиями друг друга и т. д. Пункты 2-6 описывают некоторые разумные свойства транзакций (кстати, транзакции могут вам вообще не понадобиться: (например, простое get и put по ключу еще не являются транзакциями), тогда не проверяйте ни один из этих пунктов), пункты 7-9 – уровень соответствия перечисленных выше свойств.
«Нативный клиент для Java/C/C++/C#» означает, что клиент для этих языков не просто генерирует запрос на языке, на котором написана база данных, и уходит в какой-нибудь IPC/JNI, а напрямую работает с базой данных.
По сути это означает, что база данных написана (в том числе) на этом языке.
Благодаря наличию таких вещей, как Protocol Buffers, Thrift и детальных, база данных, вообще говоря, может быть написана на нескольких языках.
Я 100% забыл некоторые важные свойства, напишите мне в личку и я добавлю в опрос.
В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Какие хранилища «ключ-значение» вы используете в бою? 1,48 % Aerospike 20 0,3 % ArangoDB 4 4,58 % Berkeley DB 62 0,74 % Coherence 10 1,26 % DynamoDB 17 2,07 % Ehcache 28 0,07 % FoundationDB 1 0,3 % GridGain 4 0,3 % GT.M 4 0,07 % Hamsterdb 1,3 3% Хейзел каст 18 0% Hibari 0 0% HyperDex 0 0,3% Infinispan 4 0,52% Kyoto Cabinet 7 3,1% LevelDB 42 0,52% MapDB 7 37,74% Memcached 511 0,22% NCache 3 0,59% Oracle NoSQL 8 0,15% Project Voldemort 2 53,99% Redis 731 % Риак 44 0,52 % RocksDB 7 0% Scalaris 0 0,3% SimpleDB 4 0% Sqrrl 0 0% STSdb 0 1,77% Tarantool 24 0,81% Tokyo Cabinet 11 0,3% Tokyo Tyrant 4 0% WebSphere eXtreme Scale 0 0,07% XAP 1 0,07% ZODB 1 1,62 % Другое хранилище «ключ-значение» (укажу в комментариях) 22 20,61% Реляционная база данных как хранилище «ключ-значение» (Oracle, MySQL, PostgreSQL, .
) 279 20,97% Хранение документов в формате «ключ-значение» (MongoDB, CouchDB , Couchbase, .
) 284 4,51% База данных другого типа в качестве хранилища ключей-значений (например, график: Neo4j, хранилище широких столбцов: Cassandra, HBase, .
) 61 6,13% Самописные ключ-значение хранилище 83 8,2% Я не использую хранилище «ключ-значение» 111 0,44% LMDB 6 0,07% LedisDB 1 0,15% GoLevelDB 2 0,3% BoltDB 4 Проголосовали 1354 пользователя.
1101 пользователь воздержался.
В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Какие свойства хранилища «ключ-значение» важны для вас? 62,37% Масштабируемость (хочу хранить больше/выдерживать большую нагрузку за счет добавления серверов) 358 34,84% Атомарность транзакций на одном ключе (либо записывать все изменения значения, либо ничего) 200 17,6% Изоляция транзакций на одном ключе (несколько одновременных транзакции по одному ключу запрещены) 101 33,28% Надежность (долговечность) транзакций (после окончания транзакции я точно не потеряю данные) 191 12,2% Атомарность транзакций по нескольким ключам 70 6,97% Изоляция транзакций по нескольким ключам (несколько одновременные транзакции, пересекающие ключи, запрещены) 40 6,62% Транзакции внутри серверов (изменения со временем распространяются на ЦОД/всю базу данных) 38 5,23% Транзакции внутри ЦОД (изменения со временем распространяются на всю базу данных) 30 9,41% Транзакции в вся база данных 54 44,43% Отказоустойчивость (сервер сгорел - продолжаем работу) 255 20,21% Классная отказоустойчивость (вышел ДК - продолжаем работать) 116 20,21% Репликация изменений между серверами (свойство чуть слабее масштабируемости) 116 14,11% Упорядочение по ключам (возможность перебирать ключи в отсортированном порядке, находить ближайший больший/меньший заданного ключа и т.д.) 81 20,21% Гарантии максимальной задержки ответа 116 18,47% Подписка на события по ключу 106 15,85% Логирование (какое-то, хотя бы хочется иметь возможность видеть, что происходит с базой данных для отладки) 91 5,92 % Логирование изменений с возможностью воспроизведения 34 16,38 % Асинхронное API (получил фьючерс по ключу) 94 40,07 % Хранение данные в памяти (слишком медленное обращение к диску для каждого ключа) 230 23,87% Хранение на диске (например, для надежности, если база данных не распределена) 137 10,45% Поддержка Windows (я хочу запустить базу данных на своей рабочей Windows / у меня есть сервер Windows) 60 6,1% Поддержка MacOS (я хочу запустить базу данных на моем разрабатываемом Mac) 35 5,92 % Удаленные запросы (RPC, тонкие клиенты) 34 9,23 % Собственный клиент для Java 53 11,32 % Собственный клиент для C/C++ 65 9,58 % Собственный клиент для C# 55 11,5 % Веб-интерфейс (отправка CRUD-запросов через HTTP) 66 16,2 % Интернет интерфейс для мониторинга базы данных 93 8,36% Резервное копирование в реляционную базу данных 48 28,4% Какое-то резервное копирование 163 10,63% Никакие свойства не нужны, как и хранилище «ключ-значение» в принципе 61 Проголосовали 574 пользователя.
Воздержались 1154 1154 Теги: #хранилище значений ключей #NoSQL #Высокая производительность #NoSQL
-
«Сделай Меня Красивой!» Выпуск №27
19 Oct, 24
