Встраиваемая бд которая лучше sqlite?

Question

[ettaluni]

Все мучаюсь вопросом какую бд использовать для проекта. sqlite слабовата для 10000 тыш записей с поиском по тексту и тэгам. Mysql mongose postgresql много для теоретически одного пользователя. Даже на с докером много жрет.
Нужен просто молнеиносный поиск. Задержки в больше секунду будут уже ощутимы.
Какие другие бд можно использовать, легкие, которые заведутся на ноде.

Answer 1

[acwartz]

Да нету их особо, SQlite да вроде бы Firebird умеют быть встроенными-переносными без лютого бэкграунда.
На мой взгляд у вас либо неправильная постановка задачи либо непраильная организация данных, либо тупо лень-матушка делать данные удобными для быстрого поиска.
Кроме того есть прям-прям специальные решения для быстрого полнотекстового поиска по текстам, вряд ли среди них есть встраиваемые легковесные решения, ElasticSearch тот же.

Comments

[ettaluni]

Я плох в Data science, так что скорее второе. Ок попробую тогда базу по другому построить.

Answer 2

[Сергей Горностаев]

SQLite легко справляется с поиском даже по миллиону записей.

Comments

[Алексей Уколов]

Ну, тут-то человеку надо "10000 тыш" записей "молниеносно" опрашивать...

[acwartz]

Алексей Уколов, плохо значит эти 10000 тыщ записей организованы.

[ettaluni]

Спасибо, я плох в Data science, попробую базу перестроить. Думал sqllite изначальна для небольших нужд. И из-за того что файловая быстро работать не может априори

[Сергей Горностаев]

ettaluni, тут даже близко нет никакой science. И вы думаете, что PostgreSQL или MySQL работают не с файловой системой?

[Flying]

ettaluni, А почему файловая система априори не может быстро работать? Даже если забыть о существовании кэшей файловых систем, у топовых SSD скорость доступа на чтение давно уже превышает несколько гигабайт в секунду, да и файловые системы в RAM дисках вполне себе существуют.

Конечно записи разные бывают, но по многогигабайтной базе без предварительной подготовки вам всё равно за секунду никакая база ничего не найдёт, а вот по подготовленным индексам - вполне, правда это уже вероятно будут более специализированные решения.

[Saboteur]

файловые системы в RAM дисках вполне себе существуют.

И они уже уступают в скорости чтения с pciexpress SSD ;)

[ettaluni]

Сергей Горностаев, А где я сказал про файловую систему? Я говорил про файловые субд.

[ettaluni]

Flying, У меня ssd и ~10000 sqllite делает запросы с задержками, не молниеносно. Я говорю бд раньше делал простые, а тут уже сложные требования... Пойду поучу scince, и про индексы тоже.

[Евгений Шатунов]

ettaluni,

Я говорил про файловые субд.

А можешь назвать известные тебе примеры файловых субд?

[ettaluni]

Евгений Шатунов, Их есть небольшое количество. Думаю нет смысла здесь описывать, погугли. Каких то особых я не знаю, если ты это спрашиваешь, только самые известные

[Евгений Шатунов]

ettaluni, пока все выглядит так, будто ты абсолютно не понимаешь что пишешь.
Давай на пальцах тебе растолкую. СУБД - Система Управления Базами Данных. Коротко - система администрирования БД.
БД - База данных.
Прочитай в первых строках readme, чем является sqlite, для примера.

Сергей тебе конкретный вопрос задал. Рекомендую ответить на него хотя бы себе самому. Но лучше, конечно, ответить Сергею.

[ettaluni]

Евгений Шатунов, Евгений ты потратил время на то чтобы доказать что я не прав, но при этом ни потратил ни одного чтобы дать ответ или приложить какое либо решение. Зачем ты мне доказываешь что я ничего не понимаю, если ранее я писал что плох в области scince и базах?
Когда я говорил про субд, под файловой я подразумевал режим работы когда пишутся данные напрямую в файл. Мне достаточно считать sqllite + драйвер + ORM некой условной субд, из sqllite все равно ничего больше не получить кроме файлового режима работы.
Поэтому вопрос Сергея я и не понимаю, Mysql-Postgres совершенно по другому работают, хранят страницы в RAM, кэширует и.т.п — это совершенно другой профит.
Но я думаю Сергей тоже меня не понял.

[Сергей Горностаев]

ettaluni, SQLite тоже кэширует. Она вообще умеет почти всё, что умеют полноценные СУБД. У неё два "минуса" - отсутствие сетевого доступа и низкопроизводительный конкурентный доступ. Если вы обращаетесь к ней локально и из одного потока, то скорость должна быть ровно той же, что и любой другой СУБД.

[ettaluni]

Сергей Горностаев, Ок, спасибо изучу вопрос, попробую ее заставить работать быстрее.

[Евгений Шатунов]

ettaluni, тебя никто не понял. Ты ничего не знаешь, ты не можешь оперировать общей терминологией. Ты что-то одно пишешь и что-то другое подразумеваешь. С такой позицией ты очень долго будешь ждать решений.
Пока видно что тебе и ответы не нужны.
Когда тебе задают вопросы подобные моему или вопросу Сергея, тебе нужно в самые короткие сроки разобраться в том что ты уже написал и найти свои очевиднейшие ошибки.

[DevMan]

ettaluni,

я плох в Data science

Пойду поучу scince

плох в области scince

кроме знания терминов неплохо было бы ещё знать их значение.

Answer 3

[Arris]

С поиском по тексту и тегам - это в смысле полнотекстовый поиск?

Попробуйте manticore. https://manticoresearch.com/

Но вряд ли оно встраиваемое. Но уж точно полегче будет, чем эластик.

Answer 4

[Sanes]

Mysql чем не угодил? Девяностые давно закончились.

Answer 5

[Ivan Brezhnev]

Как вариант https://github.com/typicode/lowdb

Но там есть оговорочка)

If you have large JavaScript objects (~10-100MB) you may hit some performance issues. This is because whenever you call db.write, the whole db.data is serialized and written to storage.