@zhna

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

В базе будут храниться номера телефонов + описание примерно 200 байт под запись. 1 500 000 номеров минимум.
База будет постоянно работать на чтение и запись. Скорость критична больше на чтение - сравнение данных. Чем на запись. Что посоветуете ? До этого пользовался то ко mysql.
Примерный алгоритм работы. Пользователь ввел N - номеров в ответ ему база вернула совпадения. Если нет такова номера то номер записывается в бд.
N - может быть любым числом от 1 до ∞.
Это будет web приложение на vue+ssr на бэке express graphQl
Какие данные дать еще для подбора базы данных под задачу ?
По возможности подскажите еще ORM для предложенной вами БД.
  • Вопрос задан
  • 124 просмотра
Решения вопроса 1
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 на порядок.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
Deissh
@Deissh
I like Python, Node.JS, Go, pain, bugs and my cat.
Будет достаточно использовать MongoDb с кешированием в памяти, так как 1.5кк записей (по 200 байт) будет занимать не более 0.4 гб.
Ответ написан
Комментировать
leahch
@leahch
3D специалист. Dолго, Dорого, Dерьмово.
Можно elasticsearch прифигачить, как раз под вашу задачу. Mongo тоже ничего, подойдет. Я за первый.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы