Некоторые новые функции MySQL не будут доступны в Community-версии

>Если смешать 90% варенья и 10% дерьма, то получится дерьмо. Но для тебя, быдло, - варенье. так что продолжай ржать (или жрать?)

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

>курите википедию

Курите топик вверх - я его сам назвал. И что еще?

>А чо, производные от GPL уже можно делать не под GPL?

С чего ты взял что они производные GPL?

>Примеры будут? Или, как обычно?

Любая компания на которую ты работаешь является владельцем имущественных прав на результаты твоей деятельности. Прочитай любой договор. Ты где работаешь? Ты что - договора не читал на основании которого вообще работаешь?

>Допустим у вас есть всего каких-то жалких 64 Гига данных. Они влезают в память ;) (4 ноды по 16 гигов). Помним еще про HA

Помните про то что на такой конфигурации - failure одного нода обозначает failure кластера потому что четверь данных становиться недоступной. Где вы тут HA увидели - не пойму.

>А если без RDBMS то как вы собираетесь с данными работать?

Без реляционной декомпозиции.

>На каком языке запросы писать?

На удобном мне.

>Как обеспечите ссылочную целостность, консистентность, транзакции ?!?

Ссылочная целостность обеспечивается самими данными которе хнанятся в памяти потмоу что не дереференсинга на ключах, а транзакции это к вашему сведению понятие не только из области _реляционных_ баз данных. НАпример осильте апачевскую либу Commons Transactions - она обеспечивает их и на диске и на памяти.

>А ведь нужно еще копировать данные по кластеру чтобы при отказе ноды система продолжила работу...

При вешей конфигурации - 64x4 - это невозможно.

>Я понимаю что в принципе можно используя кластерный кэш раскидать данные по нодам, а сами данные хранить как объекты и сверху придумать хитрые методы для индексации, НО в итоге получится багливая недо-DBMS.

DBMS в этом случае _вообще не нужна_. Вы задумывались почему гугл не хранит данные в мегамускуле - нет? И мегаоракле не хранит? НА счет багливых недо-дбмс - вы попробуйте сначала а потом сказки рассказывайте. Такая недодбмс ваши майскюэльные кластера сделает по скорости просто легко.

>А чо, производные от GPL уже можно делать не под GPL?

Нет конечно. Но тут речь идет о действиях владельца исключительных прав.

А для него этот кода не является "производным от GPL".

>> Обычно в европейских конторах ИЗНАЧАЛЬНО такой пункт в договоре есть.

>Примеры будут? Или, как обычно?

Иногда такой пункт просто не нужен, т.к. существует ст.1295 ГК РФ

>О ещё один неудачник, приведи пример того, что в ней плохого, если Ты её читал хотя бы...:)

Требование передачи копирайта на код чужой компании.

> Специально для тех кто не владеет вопросом: ключевое слово в кластере не "большой обьем данных". Ключевое слово - HA. High Availability. Высокая степень доступности сервера.

еще один оракул. репликация данных и прочие способы достижения ha прямого отношения к понятию кластер не имеют.

> Кстати, если у вас скажем 10 серверов по 16 гиг, то вы сможет хранить в кластере не такой уж мелкий обьем данных..

при чем здесь количество нодов? в mysql _каждый_ из них _обязательно_ должен вмещать все данные в оперативную память. конечно, если только не использовать data partitioning, но это уже к кластеру отношения не имеет.

>Требование передачи копирайта на код чужой компании.

А процитировать соответствующий пункт лицензии слабо? Или чукча не читатель чукча чужойбредповторятель?

> в mysql _каждый_ из них _обязательно_ должен вмещать все данные в оперативную память. конечно, если только не использовать data partitioning, но это уже к кластеру отношения не имеет.

Не там все хитрее. ТАм надо 48 серверов поставить - чтобы уместить его упомянутые 64G в память нужно 64G * 2 реплики * 1.1 / 15GB (1 гиг оставим остальному) = 10нодов только для NDB серверов (это те внутренние сервера которые собственно кластер) - а для организации доступа к ним надо будет еще MySQL фронтенды ставить плюс management node. А от 8 нодов уже нужен дедикейтед интерконнект - гигабита уже мало. Короче если сказочники думали что они поставят 2 машины с мускулем и у них нарисуется кластер который их блог ускорит доневозможности - то хрена с 2.

>А вы попробуйте "SELECT COUNT * FROM photos" сделать, когда у вас записей в таблице photos ну скажем каких-нибудь 50 тыщ. Только недавно с огорчением узнал через какую жопу постгрес это считает, кофе можно идти пить.

Не осилил индексы?

>При чем здесь количество нодов? в mysql _каждый_ из них _обязательно_ должен вмещать все данные в оперативную память

Я как раз и говорил "для тех кто не владеет вопросом". Читайте доки.

>ТАм надо 48 серверов поставить -

скажем так - в 15 легко уложимся. Однако это будет работающий кластер без single point of failure, с автовосстановлением, с возможностью дальше наращивать мощность, и с быстрым откликом. На посгресе надо еще репу почесать чтобы этого добиться.

Индексы стоят конечно - по photographable_id и photographable_type. Я привел пример для простоты. Что count(*), что count(photographable_id), что по primary key - никакой разницы по времени выборки нету. Постгрес использует индексы когда задано условие, но все еще очень медленно. Таблица простая, без blob'ов и с минимумом полей. Человек приводил выше ссылку на вики - зачитанную до дыр. Постгрес проходит всю таблицу при count, тчк. Решения - писать триггеры\вставлять разной сложности костыли. Сейчас кеширую и обновляю или по времени, или по событию.

2r: спасибо, мозг используется, без вас я бы не догадался)

2Dimez: спасибо, очень познавательно) Можно узнать использовались ли какие-нибудь ухищрения?

>Блин, а что все сразу засуетились то? Что необычного?

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

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

>скажем так - в 15 легко уложимся.

:)))

test=# explain analyze select count (id) from ser;
                                                  QUERY PLAN
-------------------------------------------------------------------------------
-------------------------------
 Aggregate  (cost=482.29..482.30 rows=1 width=4) (actual time=77.230..77.231 rows=1 loops=1)
   ->  Seq Scan on ser  (cost=0.00..415.03 rows=26903 width=4) (actual time=0.012..41.182 rows=26981 loops=1)
 Total runtime: 77.278 ms

>Помните про то что на такой конфигурации - failure одного нода обозначает failure кластера потому что четверь данных становиться недоступной. Где вы тут HA увидели - не пойму.

Согласен - "рядом" стоят еще 2 группы по 4 ноды для HA. :)

>Без реляционной декомпозиции.

Пример?

>На удобном мне.

И всех программистов проекта будуту учить этому на-коленке писанному языку?!?

>>Как обеспечите ссылочную целостность, консистентность, транзакции ?!?

>Ссылочная целостность обеспечивается самими данными которе хнанятся в памяти потмоу что не дереференсинга на ключах, а транзакции это к вашему сведению понятие не только из области _реляционных_ баз данных. НАпример осильте апачевскую либу Commons Transactions - она обеспечивает их и на диске и на памяти.

Ладно а джойны по Н-цать таблиц вы руками/циклами писать будете? И cost-based optimizer тоже свой сваяете? ГЫ сына ЛОЛ :)

>При вешей конфигурации - 64x4 - это невозможно.

См выше :)

>>Я понимаю что в принципе можно используя кластерный кэш раскидать данные по нодам, а сами данные хранить как объекты и сверху придумать хитрые методы для индексации, НО в итоге получится багливая недо-DBMS.

>DBMS в этом случае _вообще не нужна_. Вы задумывались почему гугл не хранит данные в мегамускуле - нет? И мегаоракле не хранит? НА счет багливых недо-дбмс - вы попробуйте сначала а потом сказки рассказывайте. Такая недодбмс ваши майскюэльные кластера сделает по скорости просто легко.

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

PS на Commons Transactions смотрю - вроде интересная вещь, но мне абсолютно не нужная. У нас в проектах ТОЛЬКО RDBMS плюс поддержка несколький сразу.

>> Кстати, если у вас скажем 10 серверов по 16 гиг, то вы сможет хранить в кластере не такой уж мелкий обьем данных..

> при чем здесь количество нодов? в mysql _каждый_ из них _обязательно_ должен вмещать все данные в оперативную память. конечно, если только не использовать data partitioning, но это уже к кластеру отношения не имеет.

Еще один не работавший с этим лезетЪ :) ЛОР епт ;)

БД должна влезать в память группы. Группа это набор нодов, итого если есть 4 ноды по 16Гб ОЗУ, то в теории этот кластер утянет 64Гб.

Как меня правильно поправили этого не достаточно для HA, потому создается минимум еще одна группа для резервирования данных.

Итого 2 группы по 4 ноды по 16 Гб - тянет 64Гб БД

>Пример?

Чего пример? Что реляционная моджель по вашему единственная модель представления данных? N деревьев с ленивыми ссылками.

>И всех программистов проекта будуту учить этому на-коленке писанному языку?!?

Какой ужас - я зык поиска по дереву по типу XPath изучить - наверное 2 года университета нужно....

>Ладно а джойны по Н-цать таблиц вы руками/циклами писать будете?

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

>И cost-based optimizer тоже свой сваяете?

Гы сына - ты опять живешь в области RDBMS и их архитектур. Какой оптимизер? Поиска по памяти? Поиска по индексам свободной удобной структуры?

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

>Обычные средние компании не будут писать свою софтину, а купят готовую.

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

>Группа это набор нодов, итого если есть 4 ноды по 16Гб ОЗУ, то в теории этот кластер утянет 64Гб.

Не утянет. Я привел расчет - для 64GB нужно только 10 NDB нодов + координатор + фронтэнд (оба изх которых являются failure point'ами - потому что они по одной штука) - итого минимум 12 серверов.

production_dump=# explain analyze select count(id) from photos;
                                                     QUERY PLAN                                                     
-------------------------------------------------------------------------------
-------------------------------------
 Aggregate  (cost=8758.98..8758.99 rows=1 width=4) (actual time=1999.708..1999.710 rows=1 loops=1)
   ->  Seq Scan on photos  (cost=0.00..8719.38 rows=15838 width=4) (actual time=0.890..1977.341 rows=16614 loops=1)
 Total runtime: 1999.770 ms
(3 rows)

production_dump=# explain analyze select count(*) from photos;
                                                     QUERY PLAN                                                     
-------------------------------------------------------------------------------
-------------------------------------
 Aggregate  (cost=8758.98..8758.99 rows=1 width=0) (actual time=1769.069..1769.070 rows=1 loops=1)
   ->  Seq Scan on photos  (cost=0.00..8719.38 rows=15838 width=0) (actual time=4.874..1747.887 rows=16614 loops=1)
 Total runtime: 1769.147 ms
(3 rows)



Anyway спасибо за дамп, возможно у меня неправильно сконфигурирован сервер.

>приведи пример того, что в ней плохого, если Ты её читал хотя бы

Я? тебе что-то "приводить"? Марш хавать 90-процентное варенье, а то виндотролли без тебя всё дохавают!

>Я так понял ты уже отказался от использования дерьмово лицензированных продуктов от мозиллы, бимеров, апачей, и снес из системы все под BSD и и MIT и сюда пишешь из тру-текстового термнала?

Ты тупой? Или какого хрена ты спрыгнул на BSD/MIT? Где я о них здесь говорил?

>Чего пример? Что реляционная моджель по вашему единственная модель представления данных? N деревьев с ленивыми ссылками.

>Какой ужас - я зык поиска по дереву по типу XPath изучить - наверное 2 года университета нужно....

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

OK, тогда как будет выглядеть получение из данных "пользователь N-M группа N-M права группы на объект M-1 тип действия" соотношений пользователь => объект, право.

Я реально хочу знать как это можно сделать просто и без SQL :)

>Гы сына - ты опять живешь в области RDBMS и их архитектур. Какой оптимизер? Поиска по памяти? Поиска по индексам свободной удобной структуры?

Да в области RDBMS. и отклонения от этого у нас караются... хотя преимуществ от использования чего-то другого кроме RDMBS я пока не вижу.

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

Круто. а что за задачи и какие объемы данных?

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

Интересно, а что они тогда Derby годами пишут, если можно бах... у через 1 чел/месяц (с учетом баг-фиксания) написать свое мелти-мастер транзакционное решение?!?

> Я как раз и говорил "для тех кто не владеет вопросом". Читайте доки.

я всегда подозревал, что чрезмерное употребление mysql плохо отражается на организме. эти группы в нормальных rdbms называются data partitioning.

> что они тогда Derby годами пишут, если можно бах... у через 1 чел/месяц (с учетом баг-фиксания) написать свое мелти-мастер транзакционное решение?!?

наверное, потому что решение r узкоспециализированное, и кроме как для его задачи ни на что не годно.

>Где я о них здесь говорил?

CDDL/MPL промежуточны между GPL и BSD и являются weak copyleft. Конкретизируй что конкретно тебе не нрваится в виде примеси как ты назвал дерьма в бочку меда - ослабление копилефта? Тогда мой ответ в тему - я перечислил более копилефтнослабые (вплоть до его отсутствия) лицензии.

>OK, тогда как будет выглядеть получение из данных "пользователь N-M группа N-M права группы на объект M-1 тип действия" соотношений пользователь => объект, право.

M:N термины из той же реляционной базы. Нет никаких MN. Есть ссылки в памяти. Прямые. Ничего джойнить не надо все заджойнено до нас.

>Я реально хочу знать как это можно сделать просто и без SQL :)

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

>Да в области RDBMS. и отклонения от этого у нас караются...

Религиозные трудности - это религиозные трудности. Применяя ту или иную теорию (в данном случае реляционную алгебру или ее практическую реализацию RDBMS) полезно знать границы ее применимости а так же что она не является сильвер буллет - а всего лишь один из вариантов управления данными. Далеко не единственный.

>хотя преимуществ от использования чего-то другого кроме RDMBS я пока не вижу.

В su.softw вроде кто-то пару лет назад сказал "если проект длительностью пол года и более - стоит рассматривать возможность написаняия специализированной базы данных".

Раньше и операционки разрабатывали только MS, Финский Студент, Мегауниверситет и великие корпорации - а сейчас пара студентов вполне запихивает линукс в спецдевайсы. Посмотри на последний TPC-H - там уже 2 базы - два стартапа сделали мегаораклы в 100 и более раз - просто потому что убрали зашоренность сознания типичными архитектурами и верой в то что только боги способны ваять... и сделали их в сотни раз.

>Круто. а что за задачи и какие объемы данных?

НУ я уже перечислил - одно приложение это сеть из сотен подобных связанных между собой агентов которые содержат в себе синхронное состояние между парами и полностью - то есть есть данные которые синхронны в паре агентов есть данные которые синхронны во всей сети. Меняться могут везде. В объемах на диске не скажу - не мерял - но если взять аналог из рдбмс то есть "таблицы" в которых сотни тысяч строк (эти хранятся на диске с индексами в памяти).

Второй просто большая вебаплликуха с вебовоским доступ и десктопными клиентами.

Особенности обоих в том что данные таковы что декомпозиция их в реляцонную модель - нетривиальна и объемна - проще хранить их как есть объектами - чем делать десятки/сотни таблиц - что удобнее для хранения и для синхронизации, и для миграции в следующих версиях.

Сначала обе системы делались на реляционных базах - потом этот страшный сон был забыт. В результати получили вполне транзакцционные системы с ММR, которые по скорости интерфейсов вообще не заметны.

>Интересно, а что они тогда Derby годами пишут, если можно бах... у через 1 чел/месяц (с учетом баг-фиксания) написать свое мелти-мастер транзакционное решение?!?

Обясняю - потому что они пишут универсалюную базу в рамках реляционных спецификаций. То есть они пишут базу по Кодду - чтобы на основе устоявшейся теории можно было строить системы - их решение generic. Я же говорю о специализированных решениях "под систему". Это не значит что можно выдрать либу и построить на ней любую базу. Это значит что для определенной системы с заданными условиями это заточенное спецрешение больше подходит чем generic rdbms. Это не значит что она полностью заменяет все фишки рдбмс типа постгрес - и не притендует. Это значит что она реализует необходимо под задачу подмножество способом заточенным под задачу,

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

> M:N термины из той же реляционной базы. Нет никаких MN. Есть ссылки в памяти. Прямые. Ничего джойнить не надо все заджойнено до нас.

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

>>Я реально хочу знать как это можно сделать просто и без SQL :)

> Создай на любом любимом языке программирования список польщзователей в которых будут прямые указатели на группы и т-д как ты захочешь.

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

>наверное, потому что решение r узкоспециализированное, и кроме как для его задачи ни на что не год

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

>А изменения повлекут гигантскую перестройку данных.

Не повлекут. Все твои M:N это тоже связные ключами таблицы. Другого представления данных ты и так не получишь. А запросы делать можно любые - делай что хочешь - это не влияет на схему данных - она в любом случае жестко задана.

> В su.softw вроде кто-то пару лет назад сказал "если проект длительностью пол года и более - стоит рассматривать возможность написаняия специализированной базы данных".

Однажды проходя мимо забора, я увидел на нём неаккуратно выцарапанное слово "Хуй". "И ведь в самом деле хуй" - подумал я, и прозрел что автор слова был несказанно мудр.

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

Ты не неправильно рассматриваешь ситуацию. Если у тебя "только данные" - то RDBMS тебе в руки и развлекайся. Я же говорю о ситуации когда RDBMS - это персистанс бекэнд для некой системы.

> Раньше и операционки разрабатывали только MS, Финский Студент, Мегауниверситет и великие корпорации

Т.е. практически все кому не лень.

> а сейчас пара студентов вполне запихивает линукс в спецдевайсы.

А не разрабатывает свою операционку.

> Посмотри на последний TPC-H - там уже 2 базы - два стартапа сделали мегаораклы в 100 и более раз - просто потому что убрали зашоренность сознания типичными архитектурами и верой в то что только боги способны ваять... и сделали их в сотни раз.

Что такое TPC-H? Оно как-то относится к вашим аргументам или просто снимает зашоренность сознания? Если последнее, то легально ли оно?

>Что такое TPC-H?

TPC - Transaction Processing Council - это такие страшные гики которые тестируют страшные системы типа супердомов и выкладывают результаты www.tpc.org.

>Оно как-то относится к вашим аргументам или просто снимает зашоренность сознания?

Там приммечательный факт - за несколько месяцев последних там появилось 2 конторки про которые никто не знал которые сделали атцов типа Oracle, DB2, MSSQL в сотни раз. Про одну я сюда уже постил (ParAccel Analytic Database) так как она на RH с бекэндом на Postgres. А как они сделали? А подошли к этому решению нетрадиционным образом.

>>Круто. а что за задачи и какие объемы данных? > НУ я уже перечислил - одно приложение это сеть из сотен подобных связанных между собой агентов которые содержат в себе синхронное состояние между парами и полностью - то есть есть данные которые синхронны в паре агентов есть данные которые синхронны во всей сети. Меняться могут везде. В объемах на диске не скажу - не мерял - но если взять аналог из рдбмс то есть "таблицы" в которых сотни тысяч строк (эти хранятся на диске с индексами в памяти).

Статические объемы тут мало интересны. Вы говорили, что увас это по медленным каналам разбросано. И сколько тразакций в секунду проходит? Сколько данных читается, вставляется меняется, особенно тех, которые между всеми нодами должны быть засинхронизированы?

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

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

> Особенности обоих в том что данные таковы что декомпозиция их в реляцонную модель - нетривиальна и объемна - проще хранить их как есть объектами - чем делать десятки/сотни таблиц - что удобнее для хранения и для синхронизации, и для миграции в следующих версиях.

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

> Сначала обе системы делались на реляционных базах - потом этот страшный сон был забыт. В результати получили вполне транзакцционные системы с ММR, которые по скорости интерфейсов вообще не заметны.

Перепишите её на ассемблере, получите ещё выигрыш. Только стоит ли овчинка трудозатрат дорогостоящих специалистов?

>Сколько данных читается, вставляется меняется, особенно тех, которые между всеми нодами должны быть засинхронизированы?

Это ограничено только каналом. Логика приложения такова что данные должны быть непротиворечивыми синхронными. Ганяется не много - сами изменения не частые. То есть банковских транзакций там нет - и это не ЖЖ или биллинг.

>Двухфазные транзакции?

Нет. Гарантированный транспорт. Синхронизация будет обеспечена даже если ноды недоступны. Когда появятся - тогда появятся. Перезагрузка или падение серверов - не проблема.

>Всё равняется на самую медленную ноду?

Нет - все асинхронное.

>А как распознаются несовместимые встречные изменения?

Атомарность изменения - логически законченный блок - потому варианты кошфликтов которые не разруливаются "кто последний тот и прав" минимальны. Все что входит в этот минимум разруливается так же как и в любой AsyncMMR системе.

> А с теми данными, которые на разных нодах - как производится балансировка нагрузки

Это не кластер - это аналогичные системы которые работают друг с другом. Это грубо говоря сеть серверов и локальных клиентов. Соединение между серверами в виде интерконнектаm, у локальных клиентов - к серверам - при этом все функционируют похожим образом (клиенты даже сложнее потому, что они на нереальных IP и сервер установть связь с ними on demand не может).

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

Уместно рассматривать такую возможность. Она в общем плане гласит следубщее - RDBMS может не быть самым удобным хранилищем данных - возможно можно сделать более удобное. Дальше выбор - оно подходит или нет. В случае с сетевой системой именно отказ от rdbms решил большинство проблем связанных с Async MMR и позволил одну и ту же систему в качестве ядра использовать как для разработки серверного ПО так и для десктопного у которого разница с серверным в этом смысле только значительно меньшие объемы данных.

>Только стоит ли овчинка трудозатрат дорогостоящих специалистов?

Дело в том что сложного то ничего в этом особенно нет. Тут главный принцип - не надо боятся экспериментировать:)

>Ганяется не много - сами изменения не частые.

К стати ганяется немного по причине того что транспорт - умный - он детектит перекрывающиеся изменения и убивает перекрытия. До того как транспорт стал умным - обемы реплик были гигабайтами и транспорт был загружен репликами страшно.

> Обясняю - потому что они пишут универсалюную базу в рамках реляционных спецификаций. То есть они пишут базу по Кодду - чтобы на основе устоявшейся теории можно было строить системы - их решение generic. Я же говорю о специализированных решениях "под систему". Это не значит что можно выдрать либу и построить на ней любую базу. Это значит что для определенной системы с заданными условиями это заточенное спецрешение больше подходит чем generic rdbms. Это не значит что она полностью заменяет все фишки рдбмс типа постгрес - и не притендует. Это значит что она реализует необходимо под задачу подмножество способом заточенным под задачу,

Ога. Т.е. вы всё-таки говорите о специализированном решении, которое почему-то насколько-то эффективно работает в ваших условиях на каком-то предопределенном наборе данных. При этом внесение изменений в представление данных требует внесения изменений в структуру данных (выше вы писали "Создай на любом любимом языке программирования список польщзователей.."), что исключает как создание многоуровневой архитектуры (т.е. создания соттветствующих уровней абстракции), так и возможность внесения изменений без полной остановки системы.

> Одна из фишек была в том что например для этой сетево системы много проблем решилось ничегонеделаньем, потому что проблемы эти существовали только, если база была реляционной. Как ты говоришь джойны и все такое. Вот не нужны они стали. И проблемы с репликацией перенеслись совсем в другую логику - вместо борьбы с referential integrity, констрейнтами и конфликтами, репликация стала атомарной, где атом - законченный логический кусок, а не "строки".

Ну вот допустим у вас иерархический реестр граждан сделан. В город приезжает семья и по ошибке они подают документы на регистрацию в два разных отделения милиции и там и там операторы начинают вводить их данные в систему. Что происходит? У вас две семьи создадутся или что? Если как-то отслеживается уникальность - по номеру паспорта например, то как обойтись без транзакции? Ну например, в отделении 1 успели ввести папу и сына, а в отделении 2 (на другой ноде) - ввели маму. После этого оператор отделения 1 вводит в систему маму, а оператор отделения 2 вводит в систему папу - как должна отреагировать система? Дать обоим отлуп, сказав что такие уже есть в базе, откатить все изменения, или откатить только часть изменений?

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

Тут нет никакого выигрыша по сравнению с реляционной базой. Сколько критериев вы используете для поиска данных - столько вам и придётся иметь. Хотите выбрать по типу "всё население дома номер пять по улице Гоголя города Н-ск Краснодарской области"? Пожалуйста: вы построите иерархию в виде области->города->улицы->дома->жители. Нормальная иерархия. Я - не против. Теперь вам заказчик говорит, что он хотел бы смотреть распределние численности пользователей различных операторов сотовой связи по первой букве фамилии пользователя (ну типа 30% пользователей, чья фамилия начинается с буквы "А", пользуются Беелайном, 31% - МТС-ом и т.д. - от базы требуется представить датасет с полями "буква", "оператор" и "процент" или матрицу, пофигу). Что вы делаете? Заводите в систему новый классификатор. И так на каждый пздох. Интеллектуал бы ещё пытался переиспользовать сегменты имеющихся индексов, но после того, как другой интеллектуал "улучшил" бы индекс на котором базировался первый интеллектуал - уволили бы обоих. Кстати, я уже начал называть это индексами. Просто мотому сама иерархия и есть индекс, классификатор, каталог - что хотите и используется так же. Спрашивается ради чего городить огород? Только для того что бы избежать необходимости читать книжку "Эффективное использование РСУБД Х"?

>>А изменения повлекут гигантскую перестройку данных. > Не повлекут. Все твои M:N это тоже связные ключами таблицы. Другого представления данных ты и так не получишь. А запросы делать можно любые - делай что хочешь - это не влияет на схему данных - она в любом случае жестко задана.

Как же не повлияет, вот вы же сами писали: "Создай на любом любимом языке программирования список польщзователей в которых будут прямые указатели на группы" - значит нужно будет перебрать все записи и переделать структуру данных. Чем это решение лучше РСУБД?

>> Не могу - я простой оператор и у меня нет права изменять данные. Вот они есть в системе и я хочу получить некоторое представление подмножества данных - каковы мои действия? > Ты не неправильно рассматриваешь ситуацию. Если у тебя "только данные" - то RDBMS тебе в руки и развлекайся. Я же говорю о ситуации когда RDBMS - это персистанс бекэнд для некой системы.

Т.е. вы сравниваете аппликейшен сервер с сервером БД. А смысл в этом какой?

> TPC - Transaction Processing Council - это такие страшные гики которые тестируют страшные системы типа супердомов и выкладывают результаты www.tpc.org.

И что? РСУБД там в пупок дышат иерархическим?

> Там приммечательный факт - за несколько месяцев последних там появилось 2 конторки про которые никто не знал которые сделали атцов типа Oracle, DB2, MSSQL в сотни раз. Про одну я сюда уже постил (ParAccel Analytic Database) так как она на RH с бекэндом на Postgres. А как они сделали? А подошли к этому решению нетрадиционным образом.

Видимо я пропустил этот ваш пост. И что, Postgres у них иерархический используется или что?

> Это ограничено только каналом. Логика приложения такова что данные должны быть непротиворечивыми синхронными. Ганяется не много - сами изменения не частые. То есть банковских транзакций там нет - и это не ЖЖ или биллинг.

Вы так чётко описали задачу, что мне всё равно придётся выдумывать абстрактные ситуации из "общих" областей.

> Нет. Гарантированный транспорт. Синхронизация будет обеспечена даже если ноды недоступны. Когда появятся - тогда появятся. Перезагрузка или падение серверов - не проблема.

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

> данные должны быть непротиворечивыми синхронными >> Двухфазные транзакции? > Нет. >> Всё равняется на самую медленную ноду? > Нет - все асинхронное.

А как такое возможно? Если транзакции не двухфазные, значит изменения заносятся в базу сразу по мере поступления. Вот скажем у вас 4 ноды: А,Б,В и Г. На ноду А пришло обновление (например, смысл изменения: "пользователю такому-то кредитов не давать ни под каким видом, под его видом орудует жулик") и обновление было нодой А разослано остальным нодам, или это изменение было сразу на всех было послано - не важно, важно, что существует момент, когда А и Б уже получили обновление, а В и Г, сидящие на экстремально медленной линии, получат эти данные.. Ну скажем через неделю (ну реально тормозит канал, хоть провайдеров режь). Синхронны ли будут данные в течение этой недели? Не противоречивы ли они будут? А если в течение недели жулик снимет в офисе, пользующем ноду Г миллионы?

>>А как распознаются несовместимые встречные изменения? > Атомарность изменения - логически законченный блок - потому варианты кошфликтов которые не разруливаются "кто последний тот и прав" минимальны. Все что входит в этот минимум разруливается так же как и в любой AsyncMMR системе.

Что такое "любая AsyncMMR"? Я имел в виду как вообще у вас обнаруживаются такие противоречивые транзакции?

>> А с теми данными, которые на разных нодах - как производится балансировка нагрузки > Это не кластер - это аналогичные системы которые работают друг с другом. Это грубо говоря сеть серверов и локальных клиентов. Соединение между серверами в виде интерконнектаm, у локальных клиентов - к серверам - при этом все функционируют похожим образом (клиенты даже сложнее потому, что они на нереальных IP и сервер установть связь с ними on demand не может).

Т.е. эта система не является примером распределенной иерархической базы данных. Это четыре отдельные системы, и целостность данных как-то обеспечивается только на уровне сервера, но не системы в целом.

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

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

>> Только стоит ли овчинка трудозатрат дорогостоящих специалистов?

> Дело в том что сложного то ничего в этом особенно нет. Тут главный принцип - не надо боятся экспериментировать:)

Что-б вам ваш стоматолог на таких же основаниях услуги оказывал :-)