Монга

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

Пг. Если нужна гибкая схема — там и для этого есть инструменты.

Мне нужно, чтобы по требованию система выдавала короткие фактологические справочки.

Конечно, если при over 100500 доков СУБД нанёт вешать ОСь, то это будет не комильфо.

А что насчёт Тарантула?

Пострес?

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

Она вроде бы слабо подходит под текущую задачу.

elasticsearch

redis данные хранит в памяти. Если нужно на диске - то ardb

гм там же ничего нет - тебе прийдется писать самому всю логику

Глянь rethinkdb, я не специалист, но на мой взгляд у неё есть свои фишки, посмотреть стоит.

В памяти не катит. На диске надо.

Напишем, не вопрос.

CouchDB вроде должен подходить по твои требования.

map/reduce умеет.

Вам нужно lazarus + база firebird + zeosdbo

Firebird умеет работать embedded, у вас будет проект который может работать из одной папки без инсталляции

Лазарус - нет. Вкуривать ещё одну ИДЕ, вспоминать Паскаль - выше моих сил.

А разве Файрбёрд умеет хранить документы?

Sqllite

Mongo, Elasticsearch... ну, может быть, Couchbase

Эластик ащще мейнстрим сейчас. На него всё что можно пихают. И что нельзя - тоже пихают.

Спасибо.

Пока на Монго смотрю.

Да, файрбёрд умеет блобы. SQL не хотелось бы, ну да ладно.

Я видел такую штуку: https://www.influxdata.com/

Честно говоря, выглядет как раз то, что нужно. На сам не использовал, хз, может пригодиться.

Лазарус поймет даже школьник (тем более на нем их и учат)

Если его освоить у вас не будет проблем с быстрым написанием десктопных программ. Остальные варианты типа Qt или питоновские биндинги намного сложнее

У тебя что там за бигдата с терабайтами данных?

Терабайтов не будет. Хотя, если поделку допиливать до коммерчески-пригодного состояния, у юзверей вполне могут быть и терабайты.

Я посмотрю, спасибо.

Легкая - Sqlite.

Не шути так больше =)

Да то они просто монетезиовать решили, запилив свой клауд. А так эта хрень бесплатна и оупенсорсна - https://github.com/influxdata/influxdb

А на чем писать будешь? У меня есть примерно похожая поделка и тоже затык с выбором базы данных. Сначала я использовал постгрес, но она плохо подходит для слабоструктурированных данных + слишком много занимает места на диске. Например таблица 12 гигабайт, построенные индексы (по трем колонкам из 10) занимают больше самой таблицы. Да и мне хотелось использовать встраиваемую базу данных, поэтому я переписал на sqlite с использованием FTS5. Скорость отличная, места занимает примерно на 30% от исходного csv в utf8, но в ней есть смертельный недостаток Как бороться с «database is locked» в sqlite?

Предварительно Си + Гтк

постгрес, но она плохо подходит

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

Привет, как твои поиски? Ничего не нашел интересного?

Привет!

Пока разрабатываю алгоритм логики.

Смотрю на монго и в сторону sqlite. Но пока не определился.

Ещё ту советуют ФБ. Небольшой опыт разработки под неё у меня есть.

Firebird?

Ага.

Но это специфическая СУБД. В общем, нужно подумать.

Интересно, можно ли на кутях под неё писать?

Возможно подойдёт графовая база. Например такая.

Возможно. Но я не силён в графовых БД.

А концепцию проекта я уже наваял, занимаюсь детализацией алгоритма логики и гуя.

А вот с базой пока затык. Как бы есть желание посильнее курнуть ФБ.

ЗЫ Проект вообще-то задумывался для работы, а я тут уходить собрался. Но походу заниматься продолжу, ибо тема сама по себе интересная и перспективная.

upd: придётся таки ускорится с плюсами =)))

Amazon Aurora

https://aws.amazon.com/ru/rds/aurora/

Проект уже реализуется.

Но спасибо.

MUMPS, например MiniM или GT.M

книга по MUMPS

правда, документоориентированность или индексы нужно пилить самому.

GT.M

как хранить блобы в MUMPS (например, pdf)

остальное ещё проще: глобалы это многомерные массивы, по сути хеш хешей. ими можно отмоделировать что угодно.

Начните с sqlite, не ошибетесь

Несли нужно быстро нарисовать интерфейс, то в паре с lazarus, он умеет работать с разными базами, особенно с zeosdbo компонентами

Интересно, можно ли на кутях под неё писать?

Все базы данных имеют драйвера или библиотеки под разные платфромы

Кстати firebird весьма неплоха, она умеет работать как в embedded варианте так и server, другие базы обе эти вещи не умеют

Firebird можно назвать более мощной альтернативой sqlite

Firebird, да, неплоха. Некий опыт работы с ней имеется. Опыт разработки небольшой, поскольку Паскаль как-то не зашёл.

Монга

Mogno...

Спасибо. Покурю на досуге.

Может стоит какую-то свою минимальную субд написать? Под задачу так сказать. Если и правда ни одна не подходит.

PostgreSQL. Там есть средства полнотекстового поиска, бегает на всём, начиная от кофеварок с записной книжкой до кластеров (надо только уметь настраивать его производительность).

Желательно noSQL

Ты можешь объяснить (самому себе хотя бы), зачем тебе под данную задачу noSQL?

Я не говорю, что noSQL - плохо, это хорошее нишевое решение для задач, где производительность реляционных СУБД является бутылочным горлышком. Если ты пишешь свой амазон или фейсбук, раскиданный по всему миру, или складываешь в реальном времени в БД информацию, поступающую от низкоуровневой системы сбора данных, возможно, тебе действительно нужен noSQL. И даже в этих случаях noSQL часто сочетают с реляционными СУБД.

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

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

Я искренне верю, что ты не из этих.

P.S.Сетевая и иерархическая модель данных — noSQL эпохи мейнфреймов — были популярны значительно раньше, чем появилась реляционная модель. Но в итоге реляционная модель их всех заборола, за исключением некоторых специальных ниш.

Она вроде бы слабо подходит под текущую задачу.

Если «пострес» — это PostgreSQL, интересно знать, как он может не подходить под такую задачу.

Я думал о собственнической СУБД. Есть некие идеи. Интерес. Но это время.

Кстати, тут выше Firebird рекомендовали, это хорошая СУБД. Можно её потыкать, если PostgreSQL покажется слишком неповоротливым (хотя 99% случаев неповоротливости PostgreSQL являются следствием неумения/нежелания читать литературу).

Выдохнул.