Тем временем...

Database models and alternatives settle back on SQL: http://blog.xeround.com/2011/01/five-predictions-for-your-database-in-2011

> Системы управления базами данных, не использующие SQL (или NoSQL-СУБД), постепенно выходят на первый план

Ага!

ни уже используются такими крупными компаниями, как Google и Facebook

Ага! Но причем сдесь Java?))) Хотя может я че упустил, просветите.

IBM_DW, если ты сейчас не ответишь на мое сообщение уже окончательно буду тебя считать ботом!

>Database models and alternatives settle back on SQL

обратно возвращаются к SQL?

Ага, ага. Есть хоть одна production-ready nosql база без копилефта? С копилефтом - BerkleyDB, а без - хрен.

Надо в один закрытый проект, а платить 5К ойро за лицензию на BDB жаба давит.

Ну как бы это статья IBM и она так называется. И хотя КО, призадумался, но можно догадаться, что базы данных больше всего интересуют ентерпрайз, а энтерпрайз на 99% состоит из java :) логика вполне очевидна.

Конечно есть веб-сервера интернета. Но они слишком сильно подсели на php+mysql и слезть практически не реально. Представьте себе портирование joomla, и всех прочих cms на NoSQL? Да кому это счастье надо, такой ценой? Поэтому NoSQL пока интересуются только энтерпрайзы. А там правит балом java.

> Ага! Но причем сдесь Java?)))

Я так и не понял ты ответил на вопрос в месаге которую коментируешь?

> Надо в один закрытый проект, а платить 5К ойро за лицензию на BDB жаба давит.

Какие требования?

Надёжность, встраиваемость, многопоточность. Нужно уметь хранить вагон KVP, быстро искать по ним, писать редко.

> Ага, ага. Есть хоть одна production-ready nosql база без копилефта? С копилефтом - BerkleyDB, а без - хрен.

Надо в один закрытый проект, а платить 5К ойро за лицензию на BDB жаба давит.

А паланкин и четыре раба к нему нахаляву не желаете? :)

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

Скорее всего, бот и есть )

IBM_dw - это бот. Об этом известно всем.

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

Видимо, не всем ))

посмотреть только через libastral.so из git-ng репы.

Если серьёзно - динамическая линковка библиотеки к приложению(клиент-сервер нежелателен), интерфейсы к чему-нибудь из .net(mono)/java/C и хранение key-value pair возможно с неуникальным ключом.

SQLite - не нравится только наличием sql. Для моей задачи SQL - несколько overkill.

За пару месяцев на ЛОРе можно понять о сути IBM_dw

http://www.linux.org.ru/jump-message.jsp?msgid=1746540&cid=1746684

http://www.linux.org.ru/show-comments.jsp?nick=IBM_dW

Три комментария за 4 года, причём только в 2007 году.

да я видел :D

Но зачем?

«Эндрю Гловер является президентом компании Stelligent Incorporated , ...Просмотрите блог Энди , там можно найти список его публикаций.»

Показательно что блог у «успешного» президента компании, мало того что лежит, так еще и вываливает весь error_reporting в stdout.

mongodb - http://www.mongodb.org/display/DOCS/Benchmarks

>IBM_dw - это бот. Об этом известно всем.

Это Оля

Но зачем?

Затем, что одно подменяется другим, более простым в случае с OR-mapping — более эффективным и быстрым.

Вся бизнес-логика сосредоточена в бинах (Plain Old Java Object — POJO) и ссылочных отношениях между активными объектами. Сложные SQL запросы с оптимизацией выборки в этом случае не нужны, так как используются в основном OR-mapping механизмы связанные с прямым отображением состояния активных объектов на строки в БД (персистентность состояния объектов обеспечивается записями в БД). Кэш данных и так в виде активных объектов в памяти, дополнительно что-то кэшировать не нужно. Методы, которые сложнее get/set, сильнее оптимизируются JIT, чем оптимизатором традиционной СУБД. Оверхед на один объект (одну «запись», или строку) в Java примерно 80 байт. Для SQL-ориентированных СУБД с учётом парсера и механизма предварительной подготовки запросов вряд ли сильно меньше.

>Системы управления базами данных, не использующие SQL (или NoSQL-СУБД) Вообще-то они вполне могут использовать SQL. NoSQL - Not Only SQL. В глаза бросилось

> Если серьёзно - динамическая линковка библиотеки к приложению(клиент-сервер нежелателен), интерфейсы к чему-нибудь из .net(mono)/java/C и хранение key-value pair возможно с неуникальным ключом.

Понятно

SQLite - не нравится только наличием sql. Для моей задачи SQL - несколько overkill.

Какой-нибудь специфический функционал, помимо стандартных поиска, вставки и удаления?

Статья - очередная ИБМовская параша про свои узколобые технологии. У меня ИБМ даже висит в блэклисте.

>>IBM_dw - это бот. Об этом известно всем.

Это Оля

до февраля 2007 года наверное Оля :-) было 3 комментария.

теперь, похоже, бот.

:-)

Оля перешла в цифровое измерение! «Газонокосильщик» рулит. :)

> NoSQL - Not Only SQL

Если это аббревиатура, то почему «O» маленькая? :)

> Какой-нибудь специфический функционал, помимо стандартных поиска, вставки и удаления?

Пока не предполагается. Сложных выборок данных тоже не предполагается. Упор на чтение, предполагается что запись или удаление происходят гораздо реже.

Traditionally...

Как то ты непонятно выразился

а ACID в ынтерпрайзе не нужэн, да?

> Пока не предполагается. Сложных выборок данных тоже не предполагается. Упор на чтение, предполагается что запись или удаление происходят гораздо реже.

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

Ещё поиск по ключу и курсор на таблицу.

> > ни уже используются такими крупными компаниями, как Google и Facebook

Ага! Но причем сдесь Java?))) Хотя может я че упустил, просветите.

Facebook использует проекты Apache: Hadoop, HBase, Cassandra написанные на Java.

Этот стек на данный момент является самым распространённым в крупных компаниях долины. Так же есть решения на C++ & Erlang. Но они либо внутренние(Google BigTable, Amazon Dynamo) либо менее популярные(MongoDB, CouchDB, Riak) и чаще используются в стартапах или хакерами.

> Ещё поиск по ключу и курсор на таблицу.

Под чтением я и имел в виду поиск - значение по ключу и ключ по значению. Каким образом изначально предполагается определять ключ?

Тут кое-что нашлось - http://stackoverflow.com/questions/260804/alternative-to-berkeleydb

в частности Kyoto Cabinet. Насколько я понял из сайта, идёт под GPL/LGPL license. LGPL меня устраивает.

Статья о сепульках и о том как их правильно разводить.

ключ - хэш от уникальной строки(aka серийник например). По ключу может быть одна или несколько записей(насчёт нескольких пока ещё стоит вопрос «а нужно ли»). Значение - структура с n ValueType полями, с которыми идёт работа. Меняться эта структура будет редко.

Т.о. по факту нужна одна большая KVP таблица и несколько вспомогательных, к которым никаких особых требований не предьявляется.

Можно сделать и на SQL, но слишком уж большой предположительный оверхед в коде получается.

> ключ - хэш от уникальной строки(aka серийник например). По ключу может быть одна или несколько записей(насчёт нескольких пока ещё стоит вопрос «а нужно ли»).

Это понятно, я немного про другое - откуда программа берёт собственно ключ при работе. Он определяется на основании каких-то внешних событий (например, через сканер штрих кода)?

>Упор на чтение, предполагается что запись или удаление происходят гораздо реже.

Ок, клёво, а чем тогда какой-нибудь directory server - не NoSQL? LDAP как раз и рассчитан на несложные выборки данных с минимумом записи и максимум производительности на чтение.

> Ок, клёво, а чем тогда какой-нибудь directory server - не NoSQL? LDAP как раз и рассчитан на несложные выборки данных с минимумом записи и максимум производительности на чтение.

Из таблицы в несколько сотен миллионов строк?

В LDAP нет таблиц, учите матчасть. Бэкендом могут быть базы данных с таблицами, но это уже никого не волнует.
И таки да, в каталогах может быть сколько угодно записей, если, конечно, вы не полагаете наивно, что нет каталога, кроме AD и Microsoft пророк его.

> В LDAP нет таблиц, учите матчасть. Бэкендом могут быть базы данных с таблицами, но это уже никого не волнует.

Ну да, особенно если учесть, что сам LDAP - это протокол

>Из таблицы в несколько сотен миллионов строк?

Кстати, насчёт количества... А вы много видели реальных приложений, которые хотя бы иногда вообще чистят базы от outdated или просто ненужной информации? Я уж не говорю о том, что и базы данных (по крайней мере те, что SQL), в которых среди полей таблиц не встретишь откровенной ахинеи, либо элементарно вычисляемой по другим полям, либо вообще нигде не использующейся - тоже крайне мало. Думаю, не ошибусь, если скажу, что все эти хвалёные промышленные СУБД процентов на 80 ворочают мусором и оптимизируются так сильно прежде всего для того, чтобы эти 80% не мешали оперировать оставшимися 20-ю.

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

> А вы много видели реальных приложений, которые хотя бы иногда вообще чистят базы от outdated или просто ненужной информации?

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