LINUX.ORG.RU

Вторая волна разработки Java-приложений: Базы данных типа NoSQL

 ,


0

3

Системы управления базами данных, не использующие SQL (или NoSQL-СУБД), постепенно выходят на первый план в эру Web 2.0, поскольку они эффективно решают проблемы масштабируемости. Несмотря на то, что эти СУБД еще находятся на заре своей популярности, они уже используются такими крупными компаниями, как Google и Facebook. Базы данных, не имеющие схем, кардинально отличаются от традиционных реляционных БД, однако работа с ними на практике оказывается проще, чем кажется, особенно если проектирование начинать с разработки модели предметной области, а не реляционной схемы.

>>> Подробности

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

Ага!

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

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

anonymous ()
Ответ на: Тем временем... от SunSunich

Re: Тем временем...

>Database models and alternatives settle back on SQL

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

anonymous ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dark_SavanT ★★★★★ ()

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

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

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

Но зачем?

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

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

iZEN ★★★★★ ()

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

IvS ()
Ответ на: комментарий от Dark_SavanT

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

Понятно

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


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

deis ()

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

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

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

Это Оля

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

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

:-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

deis ()

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

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

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

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

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

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

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

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

deis ()
Ответ на: комментарий от Dark_SavanT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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