какой базы данных вам не хватает?

в какую строну лучше копать?

Копай вниз — не самое простое направление, но проделанная работа будет очевидна, а возможно даже и полезна.

Если оставить в стороне бесперспективность

То возьми ручку и бумагу и создавай БД там. БД это в первую очередь теоретическая база. Код для этого не нужен. Предполагаю, что базис для современных БД в полном объёме заложили люди, которые не умели программировать.
Поэтому поставь себе за задачу вывести какой-то (на твой вкус) показатель в максимум при наличии масштабируемости.
И вперёд и с песней.

Привет!))

Взгляни на этот пост: https://www.linux.org.ru/forum/science/12168531

У меня возникало желание погружаться в базы данных несколько месяцев назад. И теперь перешел в активную фазу.

Было бы здорово пересечься вне данного форума (думаю, самое удобное --> IRC-чат). Теперь по вопросам.

графовая база данных (типа neo4j)

Графовые БД хорошо хранят информацию, например, о человеке и его социально-демографических характеристиках (пол/возраст/предпочтения/уровень доходов). Можно использовать для хранения и (самое важное) анализа данных, особенно на предмет социальных связей между условными нодами, в роли которых выступают люди.

база данных для сбора метрик и статистики

Просвяти-ка, чо это такое? Не проще ли MariaDB + R?

объектная база данных (типа ObjectDB)

Опять же от юз-кейса.

Я интересуюсь социологической стороной хранения данных (т.е. хранением с последующей обработкой социологических данных). Опять же это подлежит коллективному обсуждению.

Просвяти-ка, чо это такое? Не проще ли MariaDB + R?

Обычно там много специфичных фич, постоянные апреагрегации данных, например downsampling чем более старые данные, или вообще изменение типов хранилищ memory->ssd->hdd->«закрома родины» вместе сто старением пары timestamp->data. Еще одна фича может быть - если пользователь разрешил, то при перегрузке по скорости записи на диск, в памяти может тоже производитья downsampling. Ну и конечно такая СУБД очень сильно оптимизирована на запись, а не на запроcы или joins. Или она может быть оптимизирована на определенные запросы очень сильно.

R

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

Вопрос, собственно, в том - чего в современном мире на самом деле не хватает?

Не хватает квалифицированных инженеров с мозгами способных доводить свои детища до ума. Недостатка в начатых и выкинутых на помойку проектов вообще нет, в том числе нет недостатка в разного рода недоБД.

СУБД начинают разрабатывать не потому что уж очень хочется что-нибудь накодить, а имея ясное представление о проблемах которые можно будет решить с её помощью. Собственно решаемые проблемы и определяют модель БД, её фичи и всё такое.

Для телеметрии у всех свои велосипеды, а чисто объектная бд вообще никому не нужна?

Будет очень нужна если придумаешь хороший сценарий использования такой бд и пропиаришь его на каком-нибудь прототипе.

мне вот лично нехватает базы а-ля rrd..даже rrd почти хорошо, но нужен простой и ясный API, под кучу платформ. и легко администрируемая.

Есть желание попробовать свои силы в написании базы данных.

Судя по контексту, ты хочешь писать не базу данных (чем занимается очень много народу), а СУБД.

Если оставить в стороне бесперспективность этого предприятия

Оно не то, чтобы бесперспективно от слова совсем, но вот с нуля, пожалуй, не стоит.

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

Ещё в PostgreSQL не было пакетов, как в Oracle. Были отдельные хранимые процедуры, для их группирования рекомендовали использовать схемы, что после адоподобных пакетов Oracle звучало больно и обидно.

Я к тому, что сейчас, на мой взгляд, более актуально не писать 100500-ю СУБД, а сделать что-то полезное для уже написанных.

Удачи.

Все есть в OrientDB

Мб стажировку где поискать? В 13 году немцы в МСК очень активно искали спеца на постгрес, свой движок пилить.

Базы данных номеров кредиток с cvc-кодами, блин. Запарили путать базы данных и СУБД.

Разве на практике это не сродние понятия?

(самое важное) анализа данных

если у тебя БД анализирует данные «на предмет социальных связей» - явно творишь какую то херь.

Литература по проектированию систем мониторинга в реальном времени.
древний пост, хранить данные о маршруте не как gps координаты миллиардами строк в месяц

Есть желание попробовать свои силы в написании базы данных.

Лишь бы уроки не учить?

какой базы данных вам не хватает?

База данных МВД. Скачать онлайн.
СУБД != БД. Так-то.

Да не БД сама...она тут как источник данных. Хотя Neo4j дает некоторые примитивные статистические анализы.

Разве на практике это не сродние понятия?

Не синонимы, по крайней мере. СУБД - это инструмент, управляющий БД.

Разработать БД - это спроектировать модель данных, создать таблицы, индексы, логику и прочие объекты, которыми будет управлять Oracle, PostgreSQL или что-то ещё.

Разработать СУБД - это написать свой Oracle, PostgreSQL, ну или хотя бы MongoDB. :)

ТС, судя по всему, хочет второе, но путается в терминологии.

По поводу твоей ссылки на декабрьскую тему: ты вот на это не смотрел, например?

Понятно, спасибо :))

По поводу твоей ссылки на декабрьскую тему: ты вот на это не смотрел, например?

Позавчера читал :)) Теперь есть стимул осваивать Postgresql.

opentsdb

Ты не сказал чем копать будешь.

P.S. Пригодился бы аналог graphite на c/c++, вместо этого жирного питоньего убожества.

P.S. Пригодился бы аналог graphite на c/c++, вместо этого жирного питоньего убожества.

Prometheus, InfluxDB, OpenTSDB.
Добро пожаловать в 2016 год.

opentsdb

мысль хорошая, НО

To actually run OpenTSDB, you'll need to meet the following:

    A Linux system
    Java Runtime Environment 1.6 or later
    HBase 0.92 or later
    GnuPlot 4.2 or later

и единственный API «HTTP API» :-(

то есть всё это как-бэ намекает, что база будет строптива, прожорлива и тормозна.

Ну мы в ней держим что-то около трех терабайт на данный момент, тормозов не обнаружено.

на фоне 3-з ТБ оно может и быстро и удобно..

но для типичных баз ~1-5 Gb которые желательно крутить на том-же хосте что пара приложений, требования чрезмерны.

Вот такой:
https://en.wikipedia.org/wiki/Essbase

Хипстеро-go, ещё хипстеро-go, жаба. Ещё варианты?

Graphite или whisper от него не подходят?

Теперь есть стимул осваивать Postgresql.

Хороший выбор, из опенсорса, наверное, лучший (это если нужен какой-никакой клиент-сервер, для локального хранилища на многих задачах может и SQLite хватить).

мне вот лично нехватает базы а-ля rrd..даже rrd почти хорошо, но нужен простой и ясный API, под кучу платформ. и легко администрируемая.

есть такое