LINUX.ORG.RU

Хочется чего-нибудь строгого и маленького

 , ,


0

3

Есть одни данные, которые надо хранить. Безрезультатно пытаюсь найти хранилище своей мечты для nodejs. js славится своим пластилиновым подходом к типизации, поэтому хотелось бы хранилище построже в плане типов данных. sql или nosql значения не имеет.

  • Mysql/Postgresql слишком громоздкие для маленького проекта.
  • Тут советовали sqlite. Почитал про его type affinity, что можно записать строку в целочисленное поле, а он даже не поперхнется. Ужас по-моему. Может что-то не так понял, могу ошибаться.
  • не нашел не одного nosql решения со встроенной схемой
★★★★★

Запихни protobuf в leveldb. Вместо protobuf можно thrift. Вместо leveldb - bdb, Tokyo cabinet

Любая другая встраиваемая БД со строгими типами концептуально будет делать то же самое. Сериализировать row в низкоуровневый key value engine

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

Пока склоняюсь к варианту «Вместо protobuf - json-schema, вместо leveldb - redis». Но как-то неказисто это всё )

Любая другая встраиваемая БД со строгими типами концептуально будет делать то же самое

Суть как-раз именно в этой концептуальности, гармонично встроенной в СУБД, а не прилепленной сбоку

makoven ★★★★★
() автор топика
Последнее исправление: makoven (всего исправлений: 2)
Ответ на: комментарий от makoven

Возьми мускуль и не парься, будет запас «прочности» на вырост. А данные валидировать - клиентское дело, а не БДшное, бусинес-лоджик жэ, или как оно там.

deep-purple ★★★★★
()
Ответ на: комментарий от makoven

Я что подумал что ты о встраиваемой говоришь. Кстати не знаю почему я так решил. Редис норм, но ты в курсе что это in-memory бд? То есть она может обеспечивать durability, но полностью данные в памяти все равно

vertexua ★★★★★
()
Ответ на: комментарий от deep-purple

158 мегабайт mariadb. Мой внутренний еврей противится этому безумию)

makoven ★★★★★
() автор топика
Ответ на: комментарий от vertexua

Знаю что in-memory. Но там вроде можно настроить через сколько минут синхронизировать с диском. И не синхронизировать если нет изменений. Для редкоменяющихся данных пойдет

makoven ★★★★★
() автор топика
Ответ на: комментарий от makoven

Как раз для редко меняющихся данных никто обычно не использует in-memory, так как скорость не нужна, а места на диске больше

vertexua ★★★★★
()

Пару лет назад когда смотрел доки по sqlite там был пункт «strict affinity». Куда-то подевался. Видать автор не осилил

makoven ★★★★★
() автор топика

...Postgresql слишком громоздкие для маленького проекта.

Это не правда, PG относительно лёгкий. По крайней мере если нужна СУБД которая максимально аккуратно работает с типами, то навряд ли найдёшь что-то лучше.

mashina ★★★★★
()

что можно записать строку в целочисленное поле

ага. зачем там вообще типизация, непонятно.

crowbar
()
Ответ на: комментарий от vertexua

Как раз для редко меняющихся данных никто обычно не использует in-memory, так как скорость не нужна, а места на диске больше

А что у вас в гугле для индекса поиска используют, неужели постоянно диск сношаете?

mashina ★★★★★
()
Ответ на: комментарий от mashina

Тебе чертежи больших человекоподобных роботов не предоставить, какими гугл уже завтра планирует захватить весь мир? %)

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

Тебе чертежи больших человекоподобных роботов не предоставить, какими гугл уже завтра планирует захватить весь мир? %)

Ну мне это уже не нужно, я давно вырос из категории игрушек «детям до семи лет»

mashina ★★★★★
()

Хочется чего-нибудь строгого и маленького

Berkeley DB ?

vtVitus ★★★★★
()

nosql уже может в persistent data? или как обычно только in memory?

exception13 ★★★★★
()

NoSQL исторически появился раньше SQL-а, собственно весь ынтырпрайз до 70-х им в жопу и долбился. Потом британский ученый изобрёл теорию РБД, появление которой привело к немедленному выметанию всего этого ёбаного хаоса с рынка, стандартизации и тотальному овладиванию SQL-а в рекордно короткие сроки. Побочным эффектом стало то, что всякое быдло начало пихать SQL туда, где он не очень-то и нужен, и очень, блядь, страдать, от того, что их гостевухи стали долго загружаться. Потом кто-то сделал фундаментальное открытие - оказывается хранить профили пользователей гостевухи в хешь-таблице в памяти и доставать их оттуда по имени гораздо быстрее, чем реализовывать EAV поверх РБД. После этого переворота в мозгах гостевушников они приняли радостно сверкать новым базвордом по своим блогам и хабро-хабрикам, радуясь, что им в очередной раз удалось повернуть стрелку прогресса вспять и укусить себя за жопу.

anonymous
()

Если не страшны маргинальные решения - посмотри picolisp.

В смешные 200kb всунута очень серьезная nosql базка с полноценным ORM и пролого-подобным языком запросов.

На счет строгости, правда я не уверен. Такие вещи здесь проверяются на уровне пользовательского интерфейса. На уровне данных гарантируется, того что любые типы будут обработаны вменяемым (описанным в документации) образом.

anonymous
()
Ответ на: комментарий от vertexua

застращали тебя там всякими NDA? ЛОР мониторят специально обученные сотрудники, следящие за его соблюдением? )

Harald ★★★★★
()
Ответ на: комментарий от anonymous

хочется распечатать и в рамку на стену

Harald ★★★★★
()
Ответ на: комментарий от vertexua

другая версия - никто не знает ответа на этот вопрос :) Кроме, м.б. Брина и Пейджа. Да и те забыли уже

Harald ★★★★★
()
Ответ на: комментарий от vertexua

Ну так ничего себе вопросик то )

Это же не вопросик, а отсыл к «коллегам» которые смогут рассказать как им не нужна скорость на «редко меняющихся данных»

mashina ★★★★★
()
Ответ на: комментарий от mashina

Очевидно ще что у сабжа вроде не нужно быстрое чтение, иначе он так бы и сказал. По описанию какая-то маленькая штука, которая обычно спит.

vertexua ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.