Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 13   вперед  Ctrl
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
MasterZiv
Соответственно, либо у вас есть блокировки, либо у вас есть wormhole-ы и
несериализуемые транзакции. И то, и другое, в общем, не обязательно плохо.

Мне тут кто-то подсказывал, что применяемый там механизм называется оптимистической блокировкой.
31 авг 11, 11:14    [11204671]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 29.08.2011 4:31, .ЛП wrote:
> что подаётся как архитектурные особенности и плюсы - вызывает тихое шевеление
> волос на голове.

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

Posted via ActualForum NNTP Server 1.4

31 авг 11, 11:18    [11204702]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
интересующаяся_мнением
vadiminfo,
Спасибо за мысль, возможно следует и туда заглянуть :) Я как-то рассматривала в контексте сравнения в основном с классическими РСУБД, - это, так сказать, главный акцент сравнения. Но взглянуть на вопрос чуть шире тоже не помешает.

Так я Вам и не широту, а наоброт именно акцентирование против РСУБД и предлагал искать.
Вы вместе с ними акцентируете свой удар по РСУБД, хотя, может быть, и уже взгляните. Все-таки вы как бы типа ветерок, а РСУБД как бы скала огромная. Понимаете? А так в троем Вы уже как бы типа большой ураган, может быть, сформирутете.
31 авг 11, 11:32    [11204805]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
MasterZiv
> Второй момент, касается задач, на которые ориентирована СУБД. Сейчас в мире
> приходит понимание того, что классический реляционный подход не всегда идет на
> пользу решаемых задач, посему начали придумывать всяческие отхождения от
> стандарта: in-memory, с поколоночным хранением, вообще объектно-ориентированные.
> Раз они существуют, значит это кому-нибудь нужно?

Вы видимо слабо понимаете, о чём говорите. Ни одно из вышеперечисленных вами
"нововведений" не противоречит ни стандратру (ANSI SQL), ни реляционному подходу.

Ээээ... вы сейчас про БД Викты или про перечисленные мною примеры?
Если про Викту - отсутствие жестко заданной структуры таблиц по-моему никак не вписывается в реляционную модель.
Если про примеры - нарушение принципа ACID в in-memory - прямое нарушение стандарта ANSI SQL, а объектно-ориентированная БД вообще к реляционной отношения не имеет... Разве нет? Ну, про поколоночную... соглашусь пожалуй, - только структура хранения самих данных отличается.

MasterZiv
> клиент-сервер. Но есть ощущение, что она гибче, и легче позволяет решать
> некоторые задачи. В основном учетные: когда у вас не много пользователей (30
> бухгалтеров - это и правда много) и при этом довольно много всевозможных сложных
> рассчетов. А структуры данных приходится строить такие, что черт ногу сломит.
> Вот где-то здесь она и начинает играть, по моим ощущениям.

А думаете обычные реляционные СУБД такие задачи не решают ?
Или плохо их решают ?

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

> К примеру, насколько я понимаю ситуацию, за счет того, что у них нет жесткого
> описания структуры атрибутов в таблице, они создают одну таблицу, к примеру, для
> каталога товаров, и пихают в нее все что только душе заблогарассудится: колбаса,
> значит колбаса, автомобиль, значит автомобиль. И никих вам EAV и наследуемых
> таблиц... В итоге, максимальное кол-во таблиц которое им приходилось решать для
> конкретной учетной задачи - 200.

Оптимизировать количество таблиц в реляционной СУБД -- это конечно достоойнейшая
задача. (это сарказм, если ещё кто не понял).

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

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

Ну вот смотрите что получается: у вас много таблиц, соответственно, много связей между ними. Соответственно - чтобы вытянуть нужные вам данные вам довольно часто приходится делать сложные запросы, содержащие кучу джойнов между таблицами, а то и вложенных запросов. Это все усложняет обработку. Если все напихано в одну таблицу - по идее - структура упрощается, а соответственно - и запросы тоже. Разве нет?
Второй момент: если вы не используете грязное чтение, то при формировании сложных запросов вы начинаете блокировать работу тех, кто хочет записать данные, которые вы читаете, и влетаете в проблему блокировок в итоге (я сейчас не deadlock имею в виду, а просто тормоза). Раве нет?
Чем сложнее создаваемая структура и чем более навороченные отчеты приходится мутить - тем актуальнее проблема, - даже если объем данных в общем-то не очень большой. Где-то так.
31 авг 11, 11:41    [11204872]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
интересующаяся_мнением
Guest
MasterZiv
On 29.08.2011 4:31, .ЛП wrote:
> что подаётся как архитектурные особенности и плюсы - вызывает тихое шевеление
> волос на голове.

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

О! и я про то! Спасибо большое! Приятно услышать такое именно от вас, - я довольно регулярно читаю ваши посты в других топиках и уважаю ваш профессионализм.
31 авг 11, 11:43    [11204890]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54791

MasterZiv
Все СУБД либо используют блокировки хотя бы где-то, либо имеют несериализуемые транзакции
(т.е. нарушение целостности БД).

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

Posted via ActualForum NNTP Server 1.4

31 авг 11, 11:58    [11205024]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
интересующаяся_мнением
Если все напихано в одну таблицу - по идее - структура упрощается, а соответственно - и запросы тоже. Разве нет?

Нет. Иначе бы все так делали, ить это первое что приходит в голову каждому начинающему.
Живой мир не вседа просто трудно затолкать в одну таблицу.
Структура БД у Вас упрощается, а структура предметной области (ПО) то остается такой же сложной. У Вас получается несоотвествие структуры БД и ПО. Тут уже не до сложности запросов, тут хоть бы их вообще было ясмно как писать. Ну не говоря уже об ОЦ - нельзянавязать ф-зависимости, избыточность. Т.е. затруднено обеспечение и контроль соотвествия данных ПО. Т.е. даже если и напишите запрос, верить иму трудновато буит.
31 авг 11, 12:36    [11205285]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
tanglir
Member

Откуда:
Сообщений: 28966
+
Ну вот смотрите что получается: у вас много таблиц, соответственно, много связей между ними. Соответственно - чтобы вытянуть нужные вам данные вам довольно часто приходится делать сложные запросы, содержащие кучу джойнов между таблицами, а то и вложенных запросов. Это все усложняет обработку. Если все напихано в одну таблицу - по идее - структура упрощается, а соответственно - и запросы тоже. Разве нет?
Второй момент: если вы не используете грязное чтение, то при формировании сложных запросов вы начинаете блокировать работу тех, кто хочет записать данные, которые вы читаете, и влетаете в проблему блокировок в итоге (я сейчас не deadlock имею в виду, а просто тормоза). Раве нет?
Чем сложнее создаваемая структура и чем более навороченные отчеты приходится мутить - тем актуальнее проблема, - даже если объем данных в общем-то не очень большой. Где-то так.
vadiminfo вам тут уже советовал сходить в "Другие СУБД" - похоже, совет был пророческим: вы почти дословно повторили "аргументы" Дедала. За критикой такого подхода - милости просим сюда. Ну и сюда, на первую сотню страниц ;)
31 авг 11, 12:40    [11205318]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Vladimir Baskakov
Member

Откуда:
Сообщений: 2006
MasterZiv
..............
конфигурациях именно этот подход не так уж и плох будет по производительности,
потому что у каждого -- своя копия БД, можно сказать, распределённая обработка
данных получается :-)

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

Уважаю романтиков. Но если от меня будет зависеть - внедрять или не внедрять такого рода самопальную технологию - не подпущу и близко.... аз есьмь ретроград.
интересующаяся_мнением
Если про Викту - отсутствие жестко заданной структуры таблиц

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

интересующаяся_мнением, как бы Вы подвели итог дискуссии к этому моменту? Что нового, интересного, неожиданного для Вас прозвучало? На мой взгляд - обсуждение шло вполне предсказуемо....
31 авг 11, 12:56    [11205440]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
интересующаяся_мнением
Gluk (Kazan)
Не сообщат "они" ничего. Они тупо будут не в курсе, что бухгалтер унес домой 4,5 и 6 и радостно согласятся, что да их номер 3 самый последний. А вот когда бухгалтер на следующий день придет ... то да, лягут все

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


Лучше бы они легли :)
Альтернативные, как Вы их назвываете, данные зачастую гораздо хуже чем останов системы
31 авг 11, 13:05    [11205517]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
[quot интересующаяся_мнением]
Gluk (Kazan)
пропущено...

В файле данных всегда есть размер смещения до окончания последней транзакции, ну и время ее пишется. На что-то одно можно завязаться и проверять это при старте клиентской машины: сравнивать инфу по последней транзакции на клиенте с серверной транзакцией с этим же номером.


Это никак не затыкает дыру с данными из "альтернативной" реальности
Думайте дальше
31 авг 11, 13:08    [11205533]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
интересующаяся_мнением
Если про примеры - нарушение принципа ACID в in-memory - прямое нарушение стандарта ANSI SQL,


А с чего вы взяли, что ACID в In Memory нарушается (если явно об этом не попросить)???

интересующаяся_мнением
а объектно-ориентированная БД вообще к реляционной отношения не имеет... Разве нет?


Нет :) Они ортогональны. Например ООБД может быть построена на РБД
31 авг 11, 13:12    [11205552]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 31.08.2011 12:41, интересующаяся_мнением wrote:

Я про примеры.

> Если про примеры - нарушение принципа ACID в in-memory - прямое нарушение
> стандарта ANSI SQL,

Реляционная СУБД не обязана поддерживать ACID-транзакции.
Полно РСУБД, которые их не поддерживают.

а объектно-ориентированная БД вообще к реляционной отношения
> не имеет... Разве нет?

Нет. Не совсем.

Ну, про поколоночную... соглашусь пожалуй, - только
> структура хранения самих данных отличается.

СУБД при этом вполне себе реляционная.

> Ну вот смотрите что получается: у вас много таблиц, соответственно, много связей
> между ними.

Это не совсем верный логический посыл. Связей при этом может и вообще не быть.

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

Это никак не осложняет обработку.

Если все напихано в одну
> таблицу - по идее - структура упрощается, а соответственно - и запросы тоже.
> Разве нет?

Нет.

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

Не всегда, много СУБД сейчас поддерживают MVCC и snapshot isolation.

> Чем сложнее создаваемая структура и чем более навороченные отчеты приходится
> мутить - тем актуальнее проблема, - даже если объем данных в общем-то не очень
> большой. Где-то так.

Совсем не так.

Posted via ActualForum NNTP Server 1.4

31 авг 11, 13:36    [11205716]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 31.08.2011 12:58, Dimitry Sibiryakov wrote:

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

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

Posted via ActualForum NNTP Server 1.4

31 авг 11, 13:38    [11205732]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 31.08.2011 12:14, интересующаяся_мнением wrote:

> Мне тут кто-то подсказывал, что применяемый там механизм называется
> оптимистической блокировкой.

Ну так есть блокировки-то ?

Posted via ActualForum NNTP Server 1.4

31 авг 11, 13:40    [11205751]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54791

MasterZiv
За счёт чего сериализация-то происходит ?

Мой ХШ утверждает, что пока транзакция не обработана, следующий пакет просто не принимается.

Posted via ActualForum NNTP Server 1.4

31 авг 11, 13:43    [11205780]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
интересующаяся_мнением,
может тут уже было, но я вот не понял как без блокировок такие ситуации разруливаются

допустим оператор Маша хочет списать со счета 100 руб. Она читает остаток по счету, там 150 руб
в это же время оператор Аня с этого же счета хочет списать тоже 100 руб и она также видит что там 150 руб
смогут ли они теперь обе списать по 100 руб (при условии что отрицательный остаток недопустим)?
31 авг 11, 14:34    [11206250]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
mayton
Member

Откуда: loopback
Сообщений: 52996
Непонятно как обеспечивается оптимизация чтений. Здесь нужен какой-то индекс
который должен стать сегментом воистину неподъёмным (почти как этот
"рулон" транзакций) для рабочей станции где эта вся богадельня расположена.

В тот бред где написано что

http://spcomputer.ru/index.php?option=com_content&task=view&id=26&Itemid=37
При этом, поскольку в арсенале пользователя имеются все необходимые агрегаты, необходимое представление информации, как правило, не занимает слишком много времени (максимально длительная по времени задача за всю историю существования комплекса - 2 минуты)


я просто не верю. Возможно речь идёт о каких-то сферических отчётах в вакууме.

Дайте мне SQL-* консоль к этой Викте и я положу любого клиента в коматоз...

Либо речь идёт о смехотворных объёмах.

Я участвовал во внедрении одной из самых крупных бухгалтерии баз для *телекомов
и вовсе не понаслышке знаю сколько необходимо искать, и какую нагрузку создают
обычные SELECT.
31 авг 11, 15:09    [11206581]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Shlippenbaranus
Member

Откуда:
Сообщений: 241
Gluk (Kazan)
интересующаяся_мнением
.ЛП,
Ну не сгущайте краски-то так :)
На самом деле не все так страшно, как вы описываете. То что описываемый вами сценарий - дыра, - да. Это признаю и я и разработчик. Закрыть эту дыру не сложно, и это будет сделано.


Да ну? И как будете закрывать???
Опишите


Не вижу особенных сложностей. Навскидку - принимая транзакцию 7, клиент должен убедиться, что транзакция 6, которую он отправил на сервер вчера, действительно принята всеми. Как это сделать? Ну, например, дать уникальное имя каждой транзакции, и проверять, что последняя отправленная транзакция у тебя имеет то же имя, что и транзакция за этим же номером на "сервере". При положительном ответе клиент будет знать, что "альтернативная реальность" не возникла, и спокойно примет транзакцию 7. В противном случае клиенту придется найти последнюю транзакцию на сервере, проименованную так же, как и у него, и откатиться до нее. А потом накатить все транзакции до последней на сервере.

Т.е. кроме приоритета, у транзакций должны быть еще и уникальные имена.

(Прошу прощения, если я что-то пропустил)
31 авг 11, 15:57    [11207061]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Shlippenbaranus
Не вижу особенных сложностей. Навскидку - принимая транзакцию 7, клиент должен убедиться, что транзакция 6, которую он отправил на сервер вчера, действительно принята всеми.


А я вижу здесь сложности. Навскидку: как убедиться, что транзакция N-1 принята всеми, если Вася П. пошел на обед и выключил комп. Напоминаю, транзакции с сервера на рабочие станции идут бродкастом и, да, никаких имен и тем более приоритетов (хто здесь???) у транзакций в заявленной архитектуре не предусмотрено
31 авг 11, 16:05    [11207141]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Shlippenbaranus
Member

Откуда:
Сообщений: 241
Shlippenbaranus
Навскидку - принимая транзакцию 7, клиент должен убедиться, что транзакция 6, которую он отправил на сервер вчера, действительно принята всеми....


Плюс, в ситуации, когда каждый клиент имеет у себя, фактически, полную копию данных, хорошо бы иметь какое-либо средство контроля согласованности данных на разных машинах. Что-то вроде "контрольной суммы" всех данных. И проверять одинаковость этой "контрольной суммы" на клиенте и сервере.
31 авг 11, 16:09    [11207184]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Shlippenbaranus
Member

Откуда:
Сообщений: 241
Gluk (Kazan)
Shlippenbaranus
Не вижу особенных сложностей. Навскидку - принимая транзакцию 7, клиент должен убедиться, что транзакция 6, которую он отправил на сервер вчера, действительно принята всеми.


А я вижу здесь сложности. Навскидку: как убедиться, что транзакция N-1 принята всеми, если Вася П. пошел на обед и выключил комп. Напоминаю, транзакции с сервера на рабочие станции идут бродкастом и, да, никаких имен и тем более приоритетов (хто здесь???) у транзакций в заявленной архитектуре не предусмотрено


"Принята всеми" - значит, принята сервером. Или уточните Ваше возражение. "Приоритет" - я имел в виду, номер транзакции. А по поводу того, что никаких имен для транзакций не предусмотрено - ну, так нужно предусмотреть :). Речь о том, как заделать обнаруженную сообществом дыру.
31 авг 11, 16:17    [11207275]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Shlippenbaranus
"Принята всеми" - значит, принята сервером.


Ага, только вот "сервером" в произвольный момент времени может стать любая рабочая станция, во избежание ядерной войны, ага?
31 авг 11, 16:21    [11207331]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Shlippenbaranus
Member

Откуда:
Сообщений: 241
Gluk (Kazan)
Shlippenbaranus
"Принята всеми" - значит, принята сервером.


Ага, только вот "сервером" в произвольный момент времени может стать любая рабочая станция, во избежание ядерной войны, ага?


Да, ну и что? Продемонстрируйте по пунктам, почему от этого все вдруг повалится.
31 авг 11, 16:25    [11207387]     Ответить | Цитировать Сообщить модератору
 Re: Ни на что не похожая БД  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Shlippenbaranus
Gluk (Kazan)
пропущено...


Ага, только вот "сервером" в произвольный момент времени может стать любая рабочая станция, во избежание ядерной войны, ага?


Да, ну и что? Продемонстрируйте по пунктам, почему от этого все вдруг повалится.


Уже описывалось выше. Сейчас нет времени повторять.
Откуда у Вас такой живой интерес? Вы таки один из 2.5 разработчиков???
31 авг 11, 16:28    [11207416]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить