• Какую БД выбрать под node debian?

    leahch
    @leahch
    3D специалист. Dолго, Dорого, Dерьмово.
    Можно elasticsearch прифигачить, как раз под вашу задачу. Mongo тоже ничего, подойдет. Я за первый.
    Ответ написан
    Комментировать
  • Какую БД выбрать под node debian?

    Softovick
    @Softovick
    программист, администратор
    Самые бескомпромиссные варианты на скорость чтения и записи - база данных Redis и подобные ей (Aerospike, Tarantool). Данные хранятся в памяти, их чтение и запись максимально быстрая. Эти базы NoSQL в виде ключ-значение, то собственно всю вашу задачу покрывает с лихвой. Ключ = номер телефона, значение = описание. Можно чуть усложнить базу данных , чуть изучив структуры даннных Redis - при желании конечно.
    Единственное ограничение в случае Redis - количество ОЗУ на сервере. Под 1.5 млн записей по 200 байт понадобится больше 700МБ. Соответственно с ростом количества записей потребление памяти будет расти пропорционально. Впрочем сейчас можно найти недорогие сервера с большим количеством памяти, не то, что раньше. Потребление памяти можно распределить, используя кластерное решение, которые выглядит вроде интересным, но если честно - не очень удобным. По крайней мере не текущем этапе разработки. Надежность такой базы тоже можно увеличить, если сделать репликацию на другой сервер, где данные будут постоянно записываться на диск в режиме AOF - тогда потерять их будет сложнее, а работа с базой на мастере не будет замедлена небыстрыми дисковыми операциями. Можно этот AOF сделать и на одном сервере, если SSD - то нагрузка будет практически незаметная.
    Если есть время и достаточно опыта в разработке - можно разобраться в аналогах, у которых ограничение в ОЗУ не так сказывается. Тот же Aerospike например оптимизирован под работу на SSD, а Tarantool может хранить в себе гораздо больше данных, чем позволяет объем ОЗУ, без особых потерь производительности (так заявляют).
    Также у облачных сервисов Amazon / Azure / Google есть свои базы для key-value, можете изучить их стоимость, возможно вас устроит.

    Теоретически вы так же можете использовать MySQL или PostgreSQL, структура не настолько сложная у вас, чтобы эти СУБД не справлялись с ними. Но их производительность все будет уступать Redis на порядок.
    Ответ написан
    Комментировать