Самый быстрый, хранимый в памяти, многозадачный хранилище ключей для Node.js

Ответ 1

Я бы предложил посмотреть LMDB (который является наиболее эффективным движком для OpenLDAP и используется в ряде других open- исходные проекты).

LMDB - это встроенное хранилище ключей/значений с API Berkeley-DB или LevelDB, не нужно хранить все в памяти и поддерживать доступ к нескольким процессам. Есть привязки Node.js:

• https://github.com/Venemo/node-lmdb
• https://github.com/rvagg/lmdb (см. также этот пост)

Ответ 2

Вы можете попробовать ssdb, базу данных, совместимую с протоколом redis, построенную на leveldb.

https://github.com/ideawu/ssdb

Вы можете использовать существующий клиент node-redis, хотя некоторые из команд могут отличаться.

тесты:

                  Redis (100.000x)
      13,540 op/s ⨠ set small
      13,289 op/s ⨠ set medium
      13,279 op/s ⨠ set large
      13,651 op/s ⨠ get large
      13,681 op/s ⨠ get medium
      14,428 op/s ⨠ get small

                  SSDB (100.000x)
      12,252 op/s ⨠ set small
      11,824 op/s ⨠ set medium
      11,720 op/s ⨠ set large
      13,810 op/s ⨠ get large
      13,593 op/s ⨠ get medium
      12,696 op/s ⨠ get small


                  lmdb (100.000x)
       4,616 op/s ⨠ set small
      11,104 op/s ⨠ set medium
      17,283 op/s ⨠ set large
      13,778 op/s ⨠ get large
      16,002 op/s ⨠ get medium
      50,562 op/s ⨠ get small

                  multilevel (100.000x)
       6,124 op/s ⨠ set small
       5,900 op/s ⨠ set medium
       5,944 op/s ⨠ set large
       6,215 op/s ⨠ get large
       6,125 op/s ⨠ get medium
       6,310 op/s ⨠ get small

Как вы можете видеть, ssdb работает почти так же быстро, как redis, и он предназначен для постоянного хранения. lmdb @didier-spezia упоминается очень быстро для получения небольших данных, но установка одного происходит медленно.

Ответ 3

Существует FaceBook RocksDB, который должен быть быстрым (особенно в хранилище SSD), а также есть другие, такие как LMDB ( уже упоминалось) и WiredTiger

Вы упомянули Redis. Если вы хотите использовать Redis API, но в качестве хранилища вместо вашей оперативной памяти есть одна из вышеперечисленных баз данных Key/Value, есть два проекта, которые я знаю (хотя они их не тестировали): LedisDB (написано на Go) и ardb (написано на С++).

Недавно я начал тестировать то, что кажется очень многообещающим, хотя и менее известным (хотя я уверен, что это изменится) библиотека значений ключевых значений с именем CuttDB. Он имеет очень высокую производительность и предназначен для обработки больших объемов данных на жестком диске. Он даже включает интерфейс сервера Memcached.

Ответ 4

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

Является причиной, по которой вы хотите минимизировать память, потому что это будет встроенная база данных? Если это так, вы можете посмотреть на Empress - http://www.empress.com. Использовали его в нескольких проектах, и вы можете настроить, сколько будет загружено. Тем не менее, он получил накладные расходы на РСУБД, поэтому не уверен, что он будет таким худым, как вы хотите.

Вы также можете рассмотреть MySQL с аддоном Memcache. Это позволяет использовать MySQL в качестве хранилища ключевых значений. Гораздо быстрее, чем обычный MySQL, поскольку вы пропускаете обработку уровня SQL. Кроме того, с MySQL вы можете поворачивать ручки для воспроизведения с использованием объема памяти.

Firebird - это еще одно использование низкой памяти db - http://www.firebirdnews.org/docs/fb2min.html.

В любом случае, надеюсь, что это поможет. Без более глубокого объяснения ваших потребностей (встроено ли это, почему необходимо экономить память, и если память драгоценна, что вы считаете низким потреблением памяти, вам нужна кислота, избыточность, что вы считаете молниеносной и т.д.) Ее трудно дать больше анализа.

Ответ 5

Почему бы вам не использовать MySQL (или MariaDB) с репликацией Master-slave. Исходя из ваших требований. Архитектура master-slave MySql подходит вам.

В принципе, для NoSQL требуется много серверов. Например, минимальная настройка MongoDB требует три сервера, для HBase требуется четыре сервера.

В этой точке зрения, если вам нужна более читаемость, добавьте новый подчиненный сервер в архитектуру mysql.

Мы предполагаем, что производительность чтения mysql составляет 2 тыс. tps. Тогда четыре node производительности чтения mysql составляют 8k tps.

Это зависит от результата теста и использования службы (соотношение чтения/записи).

проверьте ниже ссылку, то есть "Марко Чеккони - Архитектура StackOverflow". http://www.youtube.com/watch?v=t6kM2EM6so4