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

Ок, из хранилища с несколькими сотнями миллионов записей. Интересует реальный опыт (я, кстати, проверял)

Ну хорошо, опишите свой опыт - может, мы вообще о разных вещах говорим?
Я могу судить только по бенчмаркам о по чужому опыту, сам действительно со столь масштабными каталогами не сталкивался.

>Если речь не идёт об удалённых записях, то это, вообще говоря, не приложению решать

Нет, не об удалённых, а как раз о тех, которые не удалили и не собираются, а надо бы. Любая СУБД должна регулярно чиститься, но, к сожалению, бизнес зачастую говорит: нам вот эти данные 10-ти летней давности могут понадобиться с вероятностью 0,00001% - и в результате записи в таблице остаются. По соседству с теми, которые востребованы здесь и сейчас на 100%.

Другими словами, Java не нуждается в сложных протоколах персистентности объектов.

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

Any sufficiently complicated NoSQL program contains an ad hoc,informally-specified,bug-ridden,slow implementation of half of SQL

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

В моём случае это было integer overflow - в пограничных условиях вылезает много чего интересного в программах, которые не ориентированы на подобные объёмы, поэтому я и интересуюсь реальным опытом

> Нет, не об удалённых, а как раз о тех, которые не удалили и не собираются, а надо бы. Любая СУБД должна регулярно чиститься, но, к сожалению, бизнес зачастую говорит: нам вот эти данные 10-ти летней давности могут понадобиться с вероятностью 0,00001% - и в результате записи в таблице остаются. По соседству с теми, которые востребованы здесь и сейчас на 100%.

В postgres для этого есть partitions

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

Какой нафиг SQL протокол??? Это язык запросов, не больше и не меньше (Simple Query Language).

И определение протокола у вас совсем хромает. Протокол - не язык.

А я здесь при чём?!

Structured Query Language — «язык структурированных запросов»

а дополнительные возможности, которые обеспечивает SQL, излишни.

Заинька ты наш, SQL это не только «чтение, удаление и изменение состояния объектов». Это еще и inner, full и outer join, sort group by, transaction, data versioning, read consistence, cost-based optimization и дофига всяких других умных слов, о которых ты даже представления не имеешь :-)

java-боту незачем знать эти словеса.

>Протокол - не язык.

О как интересно! А что же??? Вы дать определение языка в состоянии?

Integer overflow - это просто кто-то через Ж код написал, индекс перешёл границы разрядности слова.
И какой сервер каталогов так отличился?

Только требуется изощренный и сложный метод поиска чего читать, писать и удалять))) Что-то не заметил чтобы JVM дублировала. И что вы предлагаете?

Integer overflow - это просто кто-то через Ж код написал, индекс перешёл границы разрядности слова

Это был не сервер каталогов, просто показательный пример из той же серии. Я сейчас даже ссылку найду, один момент...

Да, вот она http://bugreports.qt.nokia.com/browse/QTBUG-18490

>Это еще и inner, full и outer join, sort group by, transaction, data versioning, read consistence, cost-based optimization и дофига всяких других умных слов, о которых ты даже представления не имеешь :-)

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

Использование RDBMS должно быть не менее обосновано чем применение NoSQL или любого хранилища. А то напихают данных которыё совершенно не надо хранить в реляционном виде в RDBMS - и начинаются left outer join, двадцать восемь индексов, игры со статистикой ипрочий кост-бейсед оптимизейшен и прочие extended properties только для того чтобы не тормозил поиск мессаг юзера и прочие подобные «мегазадачи».

Это еще и inner, full и outer join, sort group by, transaction...

Капитан Очевидность ты наш, ты опять перебрал что ли? Это и так понятно из моей фразы «дополнительные возможности, которые обеспечивает SQL».

Иди проспись, что ли.

Только требуется изощренный и сложный метод поиска чего читать, писать и удалять)))
И что вы предлагаете?

Уже давно предложена спецификация JSR 317 (Java Persistence API) и её реализации.

http://en.wikipedia.org/wiki/Java_Persistence_API

Можно сказать и так. Код берётся извне и я на него не влияю.

Это overkill это раз. Два - мне не нужна клиент-серверная модель. три - LDAP вообще не для этого нужен, а бэкендом у реализаций работает всё тот же BDB.

> энтерпрайз на 99% состоит из C# + .NET :)

Вы опечатались

> Заинька ты наш, SQL это не только «чтение, удаление и изменение состояния объектов». Это еще и inner, full и outer join, sort group by, transaction, data versioning, read consistence, cost-based optimization и дофига всяких других умных слов, о которых ты даже представления не имеешь :-)

Только это всё приводит к проблемам с производительностью, масштабируемостью и переносимостью.

Просто из контекста статьи вырезали предисловие...

http://www.ibm.com/developerworks/ru/library/j-javadev2-8/index.html

это не опечатка, это грубая попытка провокации :))

> а бэкендом у реализаций работает всё тот же BDB.

Бэкендом может быть абсолютно всё, что угодно, в том числе и просто файлы. BDB/HDB как основной бэкенд используется только OpenLDAP. Насколько я помню, IBM'овский каталог, например, вообще DB2 использовал до недавнего времени.
Ну и... каталог он в принципе нужен для хранения объектов самого разного назначения. Причём в Apache DS эти объекты могут быть ещё и с прицепленными к ним методами на Java. Так что если от записей перейти к объектно-оринетированному видению проблемы, то очень даже почти для всего и пойдёт.
То есть понятно, что не для реплик на форуме и не для заказов в инет-магазине, но для относительно стабильных (редко изменяемых) данных описательного характера - самое оно.

Кстати, LDAP один в один буквально накладывается на архтитектуру JNDI, интересно, какая ещё БД так может?

IBM_dW это бот.

В IBM/EEA сейчас нет грамотных технарей - одни манагеры по продажам.

Требуются знания Hibernate (реже Hibernate + JPA).

Все остальное - это бред компании И-Бэ-Мэ / ЕЕА, где в отделе железа будут предлагать pSeries + Оракле, а в самом зачуханном отделе софта - супер-пкпкр СУБД «ДиБи[л] / пополам».

Так, что ни в одном проекте я, как системный архитектор, не допущу использование поделий от ИБМ. Откатов я не беру, так как моя репутация стОит дороже. :)

так как моя репутация стОит дороже. :)

Знаем, знаем. Биореактор всегда дорожил своей репутацией.

> В postgres для этого есть partitions

Ага. Только реализация их так убога, что уж лучше без них и postgres чем с ними :)

>> Заинька ты наш, SQL это не только «чтение, удаление и изменение состояния объектов». Это еще и inner, full и outer join, sort group by, transaction, data versioning, read consistence, cost-based optimization и дофига всяких других умных слов, о которых ты даже представления не имеешь :-)

Только это всё приводит к проблемам с производительностью, масштабируемостью и переносимостью.

Вот новость! А мы не и знали.. :)

Конечно с масштабируемостью будут проблемы. Но без этих фенечек некоторые вещи практически невозможно сделать. Причем «прелесть» существующих на данных момент NoSQL в том, что поначалу все может казаться шоколадным. А потом шарах, и очередное маааленькое изменение сделать в принципе невозможно. Никак. Даже так, чтобы было медленно. :)

> Конечно с масштабируемостью будут проблемы. Но без этих фенечек некоторые вещи практически невозможно сделать. Причем «прелесть» существующих на данных момент NoSQL в том, что поначалу все может казаться шоколадным. А потом шарах, и очередное маааленькое изменение сделать в принципе невозможно. Никак. Даже так, чтобы было медленно. :)

задача базы данных - хранить данные. а так же отдавать их тогда и так, как нужно. остальные фенички ненужны. и это поняли уже лет 6 как. но некоторые продолжают двигать парадигмы 2000го года и ранее.

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

не всегда и не везде.
вот у меня сейчас в самом что ни на есть ынтырпрайзном проекте прямо в ТЗ прописано - делаем всё без транзакций, правда там про транзакции не в БД идёт речь.

Ага. Только реализация их так убога, что уж лучше без них и postgres чем с ними :)

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

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

может это http://www.rsdn.ru/forum/other/971938.flat.aspx ?

А насколько оправдано применение, например, Cassandra на всего одной машине (то есть, не распределенно)? Нужно key-value хранилище, масштабируемость особо не интересует.

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

Создание это еще пол беды. А потом получается такой неподдерживаемый ужас в схеме, что лучше спиться к чертикам и забыть.

> задача базы данных - хранить данные. а так же отдавать их тогда и так, как нужно. остальные фенички ненужны. и это поняли уже лет 6 как. но некоторые продолжают двигать парадигмы 2000го года и ранее.

Ага, конечно. :)

Когда твой уровень гормонов понизится, то быстро поймешь что часто «фенечки» ой как нужны. Тот же join. :) Так нужны, что без них совсем никак.

> Когда твой уровень гормонов понизится, то быстро поймешь что часто «фенечки» ой как нужны. Тот же join. :) Так нужны, что без них совсем никак.

про гормоны ты наверное лихо пошутил. но увы, кроме тебя шутки никто не понял.

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

>> Когда твой уровень гормонов понизится, то быстро поймешь что часто «фенечки» ой как нужны. Тот же join. :) Так нужны, что без них совсем никак.

про гормоны ты наверное лихо пошутил. но увы, кроме тебя шутки никто не понял.

Не стоит говорить за всех. :) Или может имя вам - легион?

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

Так значит иногда нужны? Я уже было подумал, что это все «парадигмы 2000го года и ранее», а риальные пацаны давно все на MongoDB да CouchDB перевели.

Посмотрим. Будет зависеть от выбора языка для написания.

RDBMS

>решать вопросы «тормознутости» RDBMS
как человек, работавший с не РСУБД (с иерархической), могу сказать, что все эти страшные слова - оборотная сторона «простоты» Коддовской алгебры. Но чем дальше в лес, тем толше партизаны. И закон рычага никто не отменял.:-)
Отсюда и костыли. Но у иерархических моделей - свои тараканы.
Хотя в общем они работают быстрее при прочих равных по сравнению с РСУБД (кроме M/Mumps, там был ещё Flare от новелл и т.д.).
А самая быстрая база - сетевая.

>оборотная сторона «простоты» Коддовской алгебры.

Естественно. И применение этой простой коддовской алгебры нужно обосновывать не меньше (еа то и больше) чем ее не применение.

> Тот же join. :) Так нужны, что без них совсем никак.

Очень часто без них никак по причине убогости модели которая не развивается со времен кодда. Как пример M:N - ужасный костыль к недостатку реляционной модели. Ограниченность полей очень примитивными типами - ужасное ограничение.

> А насколько оправдано применение, например, Cassandra на всего одной машине (то есть, не распределенно)?

Зависит от того какие данные хранить нужно и как часто они читаются/пишутся, как часто переписываются колонки с одинаковыми ключами (чем чаще - тем медленнее будет чтение по произвольным ключам). Кроме того, если использовать только как встроенное хранилище есть смысл не работать с ней через трифт, а использовать SSTable напрямую - сетевая часть у нее несколько тормознута.

Кодд

> коддовской алгебры нужно обосновывать
ну, например, ACID. в не РСУБД есть кое-какие трудности с обеспечением
общепринятых способов изоляция событий (т.н. «транзакций»).

А как идет OR-маппинг в Cassandra? или вы про другую NoSQL БД говорите?

>> NoSQL - Not Only SQL

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

Так сложилось исторически ;)

> Как пример M:N - ужасный костыль к недостатку реляционной модели.

А как отношение M:N моделируется в NoSQL? Не просто так спрашиваю. Недавно искал информацию на тему лучших практик хранения данных в NoSQL базках. Ничего толкового не нашел. Грусть-тоска-огорчение. Зато нашел несколько «прелестей», которые портят красивые сказки про легкую разработку, масштабируемость и скорость.

Ограниченность полей очень примитивными типами - ужасное ограничение.

Согласен на все 100%. Но разве нельзя использовать те же массивы и структуры? Даже PostgreSQL такое может без проблем. Впрочем, лично я бы хотел, чтобы элементами модели могли быть другие таблицы и ADT. А есть ли где такое?