×Закрыть

Постреляционность — Первые шаги

Поскольку оказалось, что на ДОУ немало вдумчивых мемберов непрочь похоливорить на тему баз данных, решил не захламлять тему о поисковике, а вынести свои мысли в отдельную ветку.

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

И как сейчас я вижу эти позиции расшатываются с двух мест.
По первой позиции есть мнение что данные они хранят не оптимально.
blog.pikosec.com/?p=95

По второй позиции есть мнение, что имеем дело с оверхедом из-за попытки построить чтото обьемное на плоском
blog.pikosec.com/?p=99

LinkedIn

Лучшие комментарии пропустить

Спорить на тему NOSQL vs RDBMS — это все равно что сравнивать ужа и ежа и спорить кто лучше.
Хотя и то и другое для хранения данных — но у них разные цели. Приведу аналогию:
RDBMS — это научная библиотека. Там каждая книжечка стоит на своей полке, есть каталог, идет строгая запись кому выдали и когда вернули и т.д. Понятное дело что все это требует большого персонала и книгу находят и приносят не быстро. Так же любые новые книги надо каталогизировать, поставить на нужную полку и только потом они станут доступны. Тут главная цель — накапливать знания и хранить их в строгом порядке, а не обслуживать читателей быстро, как в макдональсе.
NOSQL — это пачка журналов, газетных вырезок, заметок на рабочем столе. Это «рабочий беспорядок», но при этом все «под рукой». Некоторые заметки уже устарели и их не выкинули только потому, что не дошли руки. Другие повторяются в нескольких местах. Нужная информация может быть на одной странице с никому не нужным интервью забытой «звезды». Но человек, который этим пользуется может порывшись минуту найти нужную ему в данный момент информацию. И еще через минуту закинуть этот журнал в другую пачку. Так же очевидно что любой другой человек навряд-ли разберется в этом хаосе.
Имеет ли смысл спорить что лучше? Очевидно, что далеко не каждый расставляет дома книги по каталогу. С другой стороны хорошему специалисту довольно часто приходится бегать в библиотеку. В реальной жизни практика учит нас применять именно тот подход, который нам удобен. В программировании, к сожалению, это не всегда так.
Думаю главная проблема в том, что мы, девелоперы, строим систему, которой сами не пользуемся и недостаточно вникаем в ее предметную область. Поэтому нам проще действовать по шаблону: выбрали NOSQL или RDBMS (что лучше знаем или что заказчику продали) — значит все будем строить по этой схеме. В результате получается библиотека там, где должны были быть столики с журналами для детей. Или наоборот: финансовая отчетность компании за 10 лет свалена в пачки документов где-нибудь в подвале.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

:-D


Некоторые из самых интересных и пугающих примеров, приведенных на конференции, описывали случаи «прочесывания» огромных баз данных для получения ответа на вопросы, которые ставит поведение клиентов. Andreas Weigend, профессор университета Стэнфорда, бывший Chief Scientist в компании Amazon, рассказал об исследовании, проведенном в Amazon, цель которого заключалась в нахождении задержки (в днях) между моментом времени, когда клиент первый раз нажал на ссылку, ведущую к товару, и тем моментом, когда он в конце концов купил его. Это задача необычайной трудности. Поскольку большинство нажатий не приводят к покупке, вам приходится ждать до тех пор, пока покупка не совершена, и затем возвращаться назад (часы, дни, недели) и находить в океане записей о посещении сайта то самое первое нажатие, произведенное клиентом на ссылку о товаре.

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

И что ты в этом «досье» будешь хранить?

Все что связано с пользователем — его историю.

А как ты предлагаешь это все хранить? В каком виде?

Нет.
Потому что количество задач типа «а сколько пользователей в прошлом месяце купили этот товар (или кликнули на этот баннер)» значительно превышает задачи на отслеживание действий конкретного пользователя.
И в случае досье даже такой простой запрос превратится в кошмар.

Количество аналитики физически не может превышать количество запросов с пользователем.
Например пользователь чиркает карточкой в супермаркете каждый день, а сводная таблица покупок понадобится только в конце месяца.

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

Наоборот, у пользователей есть накопительные скидки. Есть разные акции типа «купи за месяц пять бритв и получи скидку 3% на приобретение шестой в следующем чеке».
И так далее. Это все поведенческие факторы. Это означает что в реляционке придётся на каждый чих гонять тяжелейшие запросы.

А аналитика на то и аналитика что нужна трём бухам в конце месяца. Кстате ничо не мешает сделать отдельное досье и вести его параллельно (дубли)

Это означает что в реляционке придётся на каждый чих гонять тяжелейшие запросы
Это вообще чистый легкий OLTP и с ним более чем сносно справляется любое кассовое ПО в режиме реального времени (между идентификацией скидочной карты и выбиванием чека). Тупой select sum по индексу из двух связанных по ID карточки таблиц. Где там тяжесть?
А аналитика на то и аналитика что нужна трём бухам в конце месяца
Та да — те же остатки на складах конечно трем бухам надо и не чаще раза в месяц. Заказ они, очевидно, по фазам луны делают. Особенно на продуктовый скоропортящийся товар или полуфабрикаты для кулинарии или ресторана, например.
Я практически досконально знаю механику работы розницы и ресторанов, т.к. внедрял такие системы. Не надо гадать — просто принимайте информацию.
Тупой select sum по индексу из двух связанных по ID карточки таблиц.

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

Та да — те же остатки на складах конечно трем бухам надо и не чаще раза в месяц. Заказ они, очевидно, по фазам луны делают. Особенно на продуктовый скоропортящийся товар или полуфабрикаты для кулинарии или ресторана, например.
Я практически досконально знаю механику работы розницы и ресторанов, т.к. внедрял такие системы. Не надо гадать — просто принимайте информацию.

Я немного не про это говорил. Возьмем пример — Ашан из 50 касс, смена 12 часов, на каждой кассе очередь и каждые 10 секунд в среднем пробивают товар на кассе.
Итого за 10 секунд 50 операций. За минуту 300 операций. За час 18 тысяч. За 12 часов почти 220 тысяч запросов пользователей с подсчетом акций и скидок.

Неужели за сутки бухи и кладовщики одной точки Ашан отправляют 220 тысяч запросов ? Я про это говорю. Что аналитических запросов всегда меньше на порядки чем операционных.

В таблице может быть сотни миллионов записей
С определенного количества записей реляционки начинают работать плохо, это факт. Партиционирование спасает в определенных случаях, но в данном значительно проще применить аргегацию — раз в сутки суммировать покупки за последние сутки и плюсовать к карточке.
Некоторый костыль, но работать будет.
.
Скидочная система вообще может не существовать — это необязательный атрибут для ритейла, а вот склады-заказы-производство есть у всех обязательно.
И, кстати, движняк по товарам не меньше, т.к. они участвуют во всех транзакциях на кассе в том числе и без скидок (и таких более 50%), а их движение тянет за собой целую бороду сопутствующих транзакций.
С определенного количества записей реляционки начинают работать плохо, это факт.
Факт.
Партиционирование спасает в определенных случаях, но в данном значительно проще применить аргегацию — раз в сутки суммировать покупки за последние сутки и плюсовать к карточке.
Некоторый костыль, но работать будет.

Костыль.

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

Скидочная система это пример. Всегда есть пересчеты балансов, процентов и тп.

И, кстати, движняк по товарам не меньше, т.к. они участвуют во всех транзакциях на кассе в том числе и без скидок (и таких более 50%), а их движение тянет за собой целую бороду сопутствующих транзакций.

Меньше движняк.

Вполне может превышать. Пользователь чиркает карточкой раз в неделю, а запрос «чиркал ли кто сегодня» выполняется каждый час.

Это где такие магазины где 1 покупатель раз в неделю и при этом целая команда аналитиков и бухов ?

Продажи самолетов, например.

А зачем продажи самолётов мониторить каждый день ?

Ух ты, какой интересный холивар. Откуда Вы берете время на обсуждение? Я даже прочитать все не успеваю :)

Ты СОВЕРШЕННО не понимаешь в чем суть RDBMS. RDMS это не MongoDB типа «о чуваки зацените как я тремя строчками джаваскрипта вставил документ в базу». Это не псевдоинтеллектуальные обсуждения того, как твитер хранит миллиард новых сообщений. RDBMS это не Cassandra, Reddis или Hbase. RDBMS это место, где DBA могут побыть чудовищами — ужасными, бесчувственными, безразличными чудовищами, которыми они на самом деле и являются.

SQL запрос выполняется три часа, а мы смеемся. Отказало 3 диска в рейде, суточный бекап давно отвалился, а мы смеемся.

Нас заставляют поддерживать базу данных на клипере, работающую с 80 года, а мы смеемся и просим еще. Ненормализованые схемы, хранимые процедуры в 3000 строк, хранение видеофайлов в blob полях — мы смеемся. Разрабочтик дропнул таблицы на продакшене — мы смеемся. Мы бездушно подпишемся под чем угодно, наши предпочтения не основаны на здравом смысле, бесцельные споры — наша стихия, мы — истинное лицо энтерпрайза.

бесцельные споры — наша стихия, мы — истинное лицо энтерпрайза.
как понял фаны «MongoDB, Cassandra, Reddis или Hbase.» — тоже не в состоянии показать примеры изящных решений, чтобы «запрос НЕ выполняется три часа», после навешивания типичного количества бизнес-правил. Каждое из которых обычно само еще создает запрос на агрегированные данные, и как автор темы уверенно говорит — ну и чё что фулскан!
ну да, а что остается, ведь если key-value то отобрать по части value кроме как перебором всех value не получится. или — индексировать самому. А потом еще. и еще. и когда оно начнет тормозить, читать «Indexing Strategies».

Интересно — а любители фулскана не догадываются о разнице его работы для случаев
1 по записям фиксированного размера, с известным смещением искомого значения в ней,
2 по записям произвольного размера, с неизвестным смещением
они так научились считать такты процессора и промахов кэша, что утверждают что фулскан во втором случае будет быстрее?

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

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

Мне вообще эти стоны напоминают семинары пожилых лисперов, с темой
«ООП провалилось! Ему пора на свалку истории!»
что взамен? LISP!

какая свежая мысль...

такие же свежие мысли — вернуться в эпоху ручного ведения индексов, ручного обеспечения атомарности и индивидуального подхода к созданию каждого запроса.
Даешь MUMPS! ну встроенный ЯП конечно там надо заменить. На LISP естественно.

Нас заставляют поддерживать базу данных на клипере, работающую с 80 года, а мы смеемся и просим еще.
Да, да,
«а мы мечтаем поддерживать базу 70 года, на MUMPS»!

Может еще и о COBOLе мечтаете?

как понял фаны «MongoDB, Cassandra, Reddis или Hbase.» — тоже не в состоянии показать примеры изящных решений, чтобы «запрос НЕ выполняется три часа»

www.sql.ru/...s/stebelek/1091

int _tmain(int argc, _TCHAR* argv[])

детонька, я видел базы написанные на plain C, в 80ых. распределенных (для ArcNET), с конкуретным доступом, с автоматической генерацией форм ввода, да еще и с push оповещием..

ты меня решил очередной древностью удивить, как свежей?

Вам дали пример изящного решения классической задачи о проводках процедурно.
(не реляционно). И выполняется он судя по бенчам значительно побыстрее чем декларативная лепешка на реляционном языке.

это не изящное решение.
это — древнее решение.
от такого подхода отрасль давно отказалась, взвешивая на практике плюсы и минусы.
но вы как истинный «знаток» — не в курсе причин.

но дураки — те кто в курсе.
аха.

Причины все известны. Они, как вы правильно заметили, все написаны в рекламных буклетах за 80й год. Вот только хороший механик, если смотрит на новенькое выкрашеное авто с конвеера, видит недостатки. А «покупатель» видит одни сплошные достоинства.

Вот у вас сейчас жесткая позиция «покупателя» почему-то. Хотя если верить Вашему опыту, могла бы быть и более профессиональная позиция — механика.

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

Вот только хороший механик, если смотрит на новенькое выкрашеное авто с конвеера, видит недостатки
а пузатый болельщик видит плохую игру футболистов.

где прототипы, механик?

отя если верить Вашему опыту, могла бы быть и более профессиональная позиция — механика.
я начинал с С. уже первый проект — бизнесовый, распределенная система продажи билетов.
MUMPS, FoxPro, опять MUMPS, 1С, всякие варианты работы с RDBMS, и из Java (с ORMами и без)

Поэтому
все что вы пишите, это как юноши убежденно рассказывают мне о прекрасной жизни в СССР. Они там не жили, но знают лучше меня, того кто там жил.

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

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

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

Без проблем. Вот прототип, на сейчас у меня БД уже в 0,6 Терабайт.
Прошу вот здесь полюбопытствовать как бегает запрос, аналог:
select ... from .. where ...group by ...

Который делает апроксимацию и строит график по табличке в 56 гигабайт.
В базе находятся несколько миллиардов фактов о документах и словах

booben.com/...?q=map&s=sql.ru

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

Тоесть вдруг классическая бизнесс задача уже и не задача. И уже почемуто никого не интересует, что проводки на процедурном языке решаются в один цикл и три простых формулы. А в реляционке, внимание, в два вложенных селекта с группировками, джоином и тремя приседаниями. И конечно этот зоопарк работает в 20 раз медленнее чем процедурный подход. Он по другому работать просто не может, ну не Боги обжигали оптимизаторы запросов.

Вот прототип, на сейчас у меня БД уже в 0,6 Терабайт.
уже спрашивал — вы не знаете чем СУБД отличается от report system?
и тычите мне какой-то движок «поисковика»?
Тоесть вдруг классическая бизнесс задача уже и не задача
мдя, не лечится...
вы мне, который давно сбился со счета количества сданых в эксплуатацию решений — хотите что-то рассказать?
свеженькое.
давайте только свежатинку, а не вырытое из могил.
И конечно этот зоопарк работает в 20 раз медленнее чем процедурный подход.
пустомеля, вы сколько и каких проектов сделали на своем «процедурном подходе»? сколько заказчиков перевели, с «20 раз медленнее» на «один цикл и три простых формулы»?
уже спрашивал — вы не знаете чем СУБД отличается от report system?
и тычите мне какой-то движок «поисковика»?

Вкладка статистика там и есть отчет. И не просто отчет, а отчет с построением графика. Вкладка поиск — это поиск, а вкладка статистика это статистика = report system.

пустомеля, вы сколько и каких проектов сделали на своем «процедурном подходе»? сколько заказчиков перевели, с «20 раз медленнее» на «один цикл и три простых формулы»?

Вам определенно надо работать менеджером по продажам.
«У нас продано 100500 решений на реляционных моделях данных Оракл»

MongoDB, Cassandra, Reddis или Hbase
?
Не, не слышал. А зачем оно ?
И не просто отчет, а отчет с построением графика
QlikView не видели?

а я в нем и отчеты создавал.
вы предлагаете на ваше поделие его сменить?

вы вообще-то с какого-то подвала вылезли, что ничего не знаете о аналогичных решениях?

Ну теперь моя очередь задать вопрос

где прототипы, механик?

С

QlikView

На техже обьемах данных с аналогичным запросом.
Я посмотрю как быстро бегает.

десктоп версия — бесплатна.
скачайте и протестите.
у него кстати — in-memory column-oriented со сжатием в памяти БД.
сервер правда платный. 64итный ессно.
потягайтесь, потягайтесь.

мне тестить ваше поделие неинтересно.

А мне не надо тестить чтобы понять что оно хуже. В плане быстродействия. И наверное я вас опять очень сильно удивлю, но все начинается с самый азов СУБД, а именно поисковых алгоритмов которые стоят в самом сердце СУБД. Я имею ввиду все теже хештаблицы. Если азы работают не очень, то наверху тоже чуда не произойдет. Будет работать хуже.

типичный ответ неизлечимого невежды.

...верить надо своей интуиции.
с «третьего поста» было понятно...
чтобы потом не сожалеть о бездарно потраченном на глупца времени.

Я сам не понимаю почему вы со своим маркетинговым булшитом полезли в достаточно серьезную профильную ветку. Есть же другие темы, где толпы хомячков поют хором хвалебные речи реляционкам и готовы совершенно «авторитетно» предложить «100500» технологий к использованию. Здесь тема немножко про другое, а именно о том кто решил покритиковать реляционный подход и посмотреть чуток дальше своего носа в будуйщее. Рекламному булшиту здесь не место.
Вот с reality_hacker интересней общатся. Здесь хоть человек пытается разобраться, пишет какието тесты. А с вами достаточно неинтересный случай. Не удивлюсь что вы лет 10 уже в «менеджерах» по интеграции, причем интеграции чего и куда совсем не важно.

пустомеля, вы сколько и каких проектов сделали на своем «процедурном подходе»? сколько заказчиков перевели, с «20 раз медленнее» на «один цикл и три простых формулы»?

Много сделал проектов. Автор сторед процедуры которая занимает около 5-7 тысяч строк. С динамикой, с темповыми таблицами курсорами, 100500 под промеждуточных запросов, группировок, апдейтов, все как полагается.... да да ... и главное ниразу не процедурные стили ... ни ни ни .....ну почти sql. Кстате то что мной переписывалось на курсоры и процедурный стиль на все томже MS SQL просто преждевременно скончалось на sql.

то есть — ни одного, из интересующей меня категории проектов.

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

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

А где я на личности переходил ?

Это мне тут уже позакидовали

ответ неизлечимого невежды.
не лечится...
детонька
далеким, нём сведущим.
вопиющую некомпетентность.

И другие перлы.
Я лишь скромно замечаю, что у некоторых людей маркетинговый подход к делу.

так я это не вам писал, а Sergiy Skynin :)

когда я не вижу профи, а вижу личность — тогда и перехожу на личности.

ничего профессионального в слепой вере — а я лучший на свете, все дураки, а я Спаситель Мира — нет.

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

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

Ну, Сергей, каждый человек это личность но не каждый профессионал, ими становятся после приобретения опыта и набивания шишек и самое главное перенимание опыта у тех кто знает больше. Поэтому профессионал часто будет встречать просто личность. И ничего плохого в гоноре и самоуверенности тоже нет, по молодости ведь все такие :) И ведь как приятно когда ты такой весь самоуверенный общаешься с человеком более знающим и который открывает тебе новый взгляд на вроде бы понятные вещи и когда это происходит в приятной беседе или легком споре. Но когда более старший человек начинает «козырять» возрастом, опытом, кричать «сынок» и тд. и тп. — разве у такого захочется учиться? Сработает негативная реакция, не восприятие оппонента. Вы ведь старше и на вашей стороне не только опыт но и мудрость, будьте более снисходительны :)

разве у такого захочется учиться?
чел многократно отказался учиться у кого-либо и чего-либо.
у меня — совсем не обязательно.
более старший человек начинает «козырять» возрастом, опытом, кричать «сынок» и тд. и тп.
когда тебе начинают рассказывать о том как здорово было там где ты лично понабил немало шишек — ничего другого не остается :)
будьте более снисходительны :)
та да, надо было сразу пройти мимо. уже ж писал, решил не слушаться своей интуиции :)
и оказалось — напрасно. еще вот и вы мне выговаривать за это начали — что не прошел мимо :)
чел многократно отказался учиться у кого-либо и чего-либо.
у меня — совсем не обязательно.

Ололо, а чему у вас можно научится ?
Какие у вас реально уникальные знания есть, которых нет у других миллионов ланосоводов ( да да, у меня тоже есть «ланос» и я знаю где автосалон, это не проблема) ?

Это разговор человека который сидит в своем гараже, копается в двигателя, весь в масле и выглядит может быть даже гдето глупо. Я не исключаю. Но причем тут водила ланоса, который обвиняет жигулиста «в непрофессионализме» ?
Тебе говорят, вот посмотри на эту форсунку, она могла бы быть и лучше. Пример кода. А ты, да что это за хрень ?! Недоучка. Вон бери ланос сенс, машина ураган, в сша собирают.

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

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

водила ланоса скажет жигулисту другое — ты нищеброд что-ли?

пусть спец по форсункам не берется учить водить машину.

Так вот оно чо Михалыч ©
Джобс не стеснялся крутить свои форсунки в гараже. Гейтс
не стеснялся крутить свои форсунки на бейсике. Цукерберг
не стеснялся крутить форсунки на ПХП, а Ларри Пейдж и Брин
не стеснялись крутить форсунки на третьем курсе универа, Дуров не стеснялся крутить форсунки в рабочее время, а еще Касперски, Сегалович .... тысячи их.

Но — я теперь понял. Всё упущено. Нужно сразу в манагеры, оператор виндовз, макбук про в кейсе, цео по рекламе. А эти ботаники что форсунки в гараже крутят — недоучки ! ))

мдя. неизлечимо!!! :D

весь букет своих хворей продемонстрировали :)

Вот вам иминитому титулованому ланосоводу, (а не какомуто там форсунщику), задача на правила дорожного движения:


drop table Color

go

create table Color
(
Name varchar(256)
)

go

insert into Color(Name)
select ’Red’
union all
select ’Green’
union all
select ’Green’
union all
select ’Green’
union all
select ’Blue’

Нужно удалить из таблицы дубли, не добавляя колонку.
В один запрос. Я эту задачу решил за пол часа, когда мне ее задавали.

Ну и к теме возвращаясь, сами понимаете, что процедурно ее решить просто элементарно. На SQL нужно немного подумать.
Но судя по вашим регалиям начиная с МУМПС, это не составит вам труда ))

ЗЫ: MS SQL

Засчитывать слив ?
Прикол в том, что кто громче всего кричат о SQL его то толком и нихрена и не знают.

конечно засчитывай :)

вы кодеры «почему-то» уверены что с вами обязаны соревноваться.

впредь — всегда засчитывай. никто с кодером в скорости кодирования тягаться не будет. ну, кроме другого кодера.

Прикол в том, что кто громче всего кричат о SQL
прикол в том что в теме я просил прототип хоть чего-нибудь, и что-то что не вгоняет в «светлое прошлое». и решения не напоминающие «гильотину от головной боли»

но кодер ничего не услышал...

вы кодеры «почему-то» уверены что с вами обязаны соревноваться.
впредь — всегда засчитывай. никто с кодером в скорости кодирования тягаться не будет. ну, кроме другого кодера.

Лол, ну просто лол. На поверку, водитель который распальцовывал и рекламировал ланос, даже оказался неспособным крутить его руль. При этом, все кто крутили его рулевую колонку, назвал «кодерами и ничего не понимающими недоучками».

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

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

Короче засчитываю слив. Удачи в продаже пылесосов.

select ... from .. where ...group by ...
воу, воу, воу
Вам понятие «Хранилище данных» (Datawarehouse) о чём-то говорит?
Подходы Кимбала и Инмона изучали?
Многомерные (MOLAP) движки смотрели?
Который делает апроксимацию и строит график по табличке в 56 гигабайт.
В базе находятся несколько миллиардов фактов о документах и словах
1. И все 56 гигабайт постоянно изменяются?
2. Или они статические, а данные только приходят новые?
Если ответы 1. нет, 2. да, то Ваша задача решаема реляционным подходом.
1. И все 56 гигабайт постоянно изменяются?
2. Или они статические, а данные только приходят новые?
Если ответы 1. нет, 2. да, то Ваша задача решаема реляционным подходом.

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

Ну МОЛАП вряд ли реляционным подходом назвать можно.
НУ и про много серверов, тоже голословное утверждение.

Ниразу не голословное.
Покажите компанию у которой база на 0.5 ТБ крутится на одном дешёвом серваке за 350 баксов. Причём эта база должна справлятся на время индексирования примерно с миллиардом микро запросов в час.

Покажите компанию у которой база на 0.5 ТБ крутится на одном дешёвом серваке за 350 баксов
Ну 350 баксов это доли процента ЗП чела который эту базу обслуживает, это как гонять на лексусе между базарами выискивая где пучек укропа дешевле. Бизнес просто зачастую может позволить себе серваки подороже. Ну и 10 лет назад эти же ОЛАП базы вполне крутились на железе, которое сейчас и стоит 350 баксов.
Причём эта база должна справлятся на время индексирования примерно с миллиардом микро запросов в час.
Это 300к транзакций в секунду, это не область применения классического бизнеса который юзает ОЛАП
Вам понятие «Хранилище данных» (Datawarehouse) о чём-то говорит?
Подходы Кимбала и Инмона изучали?
Многомерные (MOLAP) движки смотрели?

Люди делятся на две категории. Те кто изучает и те кто делает.

PS: booben.com/...Кимбал&s=sql.ru

Кстате, очень точно написано. Видно что этот чел со мной на одной волне.


Хранение демонстраций ссылок — это только начало «всемирного потопа» данных, который по-настоящему случится тогда, когда тэги RFID будут помещены на каждую единицу товара. В этом случае, не только объем данных приводит в ужас, но и сами данные часто сохраняются на различных серверах, каждый из которых служит «дверью» в различные территориальные подразделения компании, географические пункты и периоды времени. Эти проблемы выдвигают на повестку дня вопрос: а является ли реляционная модель и язык SQL адекватными средствами, способными справиться с ними. Тем не менее, произвольные вопросы, которые люди хотят задавать этим данным, требуют того же типа доступа, который так успешно обеспечивался реляционными базами данных для гораздо меньших источников данных.

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

Проблема є не тільки у RDBMS, а конкретно у SQL. Сама мова робить деякі види обробки даних дуже незручними. Наприклад, немає великої потреби зберігати граф у реляційних таблицях. Одна таблиця для вузлів, інша для дуг. Але розв’язувати типові задачі на графах за допомогою SQL це жах. З іншого боку робити це у Prolog набагато простіше, хоча всі факти зберігають реляційну структуру. Це підтверджують графові бази даних, де часто є підтримка синтаксису Prolog-а для запитів.

Я все никак не доберусь покопать вариант организации данных в виде связки KVS + графовая бд / триплстор. Первая для контейнерного хранения данных, вторая для хранения структуры, связей, отношений между данными. Собственно, если о KVS я еще что то знаю, то о втором только слышал что оно есть))

Спорить на тему NOSQL vs RDBMS — это все равно что сравнивать ужа и ежа и спорить кто лучше.
Хотя и то и другое для хранения данных — но у них разные цели. Приведу аналогию:
RDBMS — это научная библиотека. Там каждая книжечка стоит на своей полке, есть каталог, идет строгая запись кому выдали и когда вернули и т.д. Понятное дело что все это требует большого персонала и книгу находят и приносят не быстро. Так же любые новые книги надо каталогизировать, поставить на нужную полку и только потом они станут доступны. Тут главная цель — накапливать знания и хранить их в строгом порядке, а не обслуживать читателей быстро, как в макдональсе.
NOSQL — это пачка журналов, газетных вырезок, заметок на рабочем столе. Это «рабочий беспорядок», но при этом все «под рукой». Некоторые заметки уже устарели и их не выкинули только потому, что не дошли руки. Другие повторяются в нескольких местах. Нужная информация может быть на одной странице с никому не нужным интервью забытой «звезды». Но человек, который этим пользуется может порывшись минуту найти нужную ему в данный момент информацию. И еще через минуту закинуть этот журнал в другую пачку. Так же очевидно что любой другой человек навряд-ли разберется в этом хаосе.
Имеет ли смысл спорить что лучше? Очевидно, что далеко не каждый расставляет дома книги по каталогу. С другой стороны хорошему специалисту довольно часто приходится бегать в библиотеку. В реальной жизни практика учит нас применять именно тот подход, который нам удобен. В программировании, к сожалению, это не всегда так.
Думаю главная проблема в том, что мы, девелоперы, строим систему, которой сами не пользуемся и недостаточно вникаем в ее предметную область. Поэтому нам проще действовать по шаблону: выбрали NOSQL или RDBMS (что лучше знаем или что заказчику продали) — значит все будем строить по этой схеме. В результате получается библиотека там, где должны были быть столики с журналами для детей. Или наоборот: финансовая отчетность компании за 10 лет свалена в пачки документов где-нибудь в подвале.

да, где-то так.

добавлю
а с инженерной точки зрения «NoSQL vs RDBMS» это выбор в пространстве CAP теоремы.

Что же до schema-less, то простота создании «пачки вырезок из журналов и газет» оборачивается головняком потом, если придется делать осмысленные выборки, результат которых не зависит от их способа.
schema-less — это по сути отказ от выяснения отношений между информацией в хранилище. перемещение выявления этих отношений из хранилища в запрашивающий данные код.

а с инженерной точки зрения «NoSQL vs RDBMS» это выбор в пространстве CAP теоремы.
Читаю этот топик, и одни фейспалмы возникают.

А что Вы видите противоречивого в этом утверждении?

НУ то что CAP, она типа перпендикулярна NoSQL и SQL, обе могут быть любой двухбуквенной комбинацией из CAP.

Я думала, что SQL — это AC. А есть ли SQL хранилища с CP? AP ведь по определению не может быть для SQL хранилища, так как нарушает ACID (так как без consistency), верно?

Я думала, что SQL — это AC
он подмену сделал :)

RDBMS это обычно AC

SQL — это всего лишь декларативный(в отличие от императивного, как в MUMPS или dBase) язык работы с данными.

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

Да, спасибо, Серёжа, я имела ввиду RDBMS. Просто часто на форумах встречаю SQL, как синоним RDBMS решений, когда контекст общения CAP, NoSQL...

А есть ли SQL хранилища с CP?
Элементарный мастер слейв с синхронной репликацией — это AP

Хотел написать: Элементарный мастер слейв с синхронной репликацией — это СP

Ага, спасибо, я так и поняла

потому и написал —

а с инженерной точки зрения
то бишь — с практической, а не академической.
с выбора того что есть в предложении, а не с того что могло бы быть.
и я написал
RDBMS
а не SQL
SQL это язык :) подобие которого прикручивают и к NoSQL базам.

из доки:
Retrieve data from a Cassandra table.

SELECT select_expression
FROM keyspace_name.table_name
WHERE relation AND relation ...
ORDER BY ( clustering_column ( ASC | DESC )...)
LIMIT n
ALLOW FILTERING

о бишь — с практической, а не академической.
Ну вот именно с практической, как настроишь — так и будет?
SQL это язык :) подобие которого прикручивают и к NoSQL базам.
из доки:
Retrieve data from a Cassandra table.
То что ты написал называется CQL. A SQL по определению требует РДБМС. Учи матчасть.
A SQL по определению требует РДБМС.

www.oracle.com/...view/index.html

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

То что ты написал называется CQL
я в курсе как называется.
там откуда копипастил даже в линке написано.
www.datastax.com/...e/select_r.html

на данном уровне детализации я написал нечто:
«Java и C#» - один и тот же язык.
конечно можно возразить что и Java 1.1 и Java 1.5 — разные ЯП
или C# 1.0 и C# 4.0
зависит от того — что выясняем.

главное свойство SQL — декларативная, непозицонная работа с данными, и наличие зафиксированных в синтаксисе операторов выбора именованых данных, источника, условий, сортировки и т.д

Если даже это главное свойство, не факт что это достаточное условие что бы называться СКЛ.
НУ и уровнями детализации можно крутить как хочешь, на одном из них ты — огурец. Можно я тебя огурцом буду называть?

Можно я тебя огурцом буду называть?
конечно можно!
«Роза пахнет розой, хоть розой назови её, хоть нет.»
не факт что это достаточное условие что бы называться СКЛ.
да, не факт что достаточное.
факт что я это имел ввиду.
факт что название CQL мне было известно.

а огурцом ты меня назови, или я тебя по старинке кулхацкером — какая разница?

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

НУ можешь не отзываться, огурец.

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

Внезапно,
CQL хоть издали и похож на SQL, но им не является.
Там нету ввообще почти всего что есть в скуэль.

Критерии по которым их отождествил я назвал.
Вы их ни асилили?

А что критерии? у це, цепее и жабы тоже синтаксис похожый, и что ?

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

Наоборот. RDBMS выглядит как огромная свалка ящичков разного размера, в которые засунуты обрывки информации. Когда клиент заходит в это хранилище, сразу приходится из 100500 ящичков тянуть кучу мукулатуры.

В одном ящичке у нас лежит: «Иван Иванов, 50 лет», в другом ящичке лежит «Женат, дети Юра, Ина, Петя», в третьем «Брал кредит на машину», в четвертом «Кредит Выгодный 5%», в пятом «Квитанции по кредитам» и тд тд тд...... ящичков сотни штук

А могло бы быть все как досье. Вот она папка о «Иване Иванове», здесь есть всё. Его биография, кредитная история, штрафы за поездки. И не нужно 1500 ящичков по всему архиву.

Вот она папка о «Иване Иванове», здесь есть всё.
а обычно требуется
выдайте мне фамилии тех у кого в этом году юбилей.
а не «всё об Иванове»

значит потребуется — индекс. Досье под названием — «Года рождения»
и таких папочок потребуется много.

Вот она папка о «Иване Иванове»
Документо-ориентированные БД так и устроены.
Или реализации, расширения RDBMS

Удобней и наглядней работать с досье.
А запросы типа «у кого в этом году юбилей» и должни делаться сложнее, чем просто получить всю информацию о человеке.

Удобней и наглядней работать с досье.
нет.

Но поясню, почему написал

да, где-то так.

а не — полностью согласен.

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

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

Например:

Брал кредит на машину

а откуда он их взял? Кто ему разрешил их оттуда взять?

Значит в реальной БД нужно будет отразить три события:
1 дата1 Иванов хочет взять кредит на машину
2 дата2 Петрова выделила Иванову деньги на кредит
3 дата3 Иванов взял кредит на машину

и по событию 2 деньги откуда-то куда-то должны быть переложены
а может и по событию 3 — еще от куда-то — Иванову в карман

в каком досье хранить эту информацию?

из каких досье выбирать:
на автомобили было выдано столько то денех

Тоже самое с покупкой.
с любым складом.

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

1 дата1 Иванов хочет взять кредит на машину
2 дата2 Петрова выделила Иванову деньги на кредит
3 дата3 Иванов взял кредит на машину

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

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

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

Вот это и пишем в досье
в чье?
или в оба — и Иванова и Петровой?
а в чьем досье хранить событие о перемещении денег по внутрибанковским счетам?
особенно когда оно осуществлено не человеком а «роботом выполняющим регламентную операцию». в Досье робота?
В крайнем случае фулскан.
при размере базы данных на порядки больше размеров оперативной памяти?
вы шутите?
Как в бухгалтерии.
ну так вот Лука Пачоли в «Трактате о счетах и записях» ek-lit.narod.ru/lukasod.htm и описал как хранить данные. чтобы — не потерялись, чтобы была видна картина, чтобы быстро искать, чтобы — их контролировать логическую целостность.
Записи в досье сущностей — это не позволяют. всякое действие — «фулскан»
Ничего не должно пропасть.
и как это проверить, что не пропало?
фулскан по всем Досье?
а может все же — ru.wikipedia.org/...лтерский_баланс
то есть записывать информацию ни куды попало, «потом разгребем!», а сразу — куда положено, по — «полочкам» и «ящичкам»?
в чье?
или в оба — и Иванова и Петровой?
а в чьем досье хранить событие о перемещении денег по внутрибанковским счетам?
особенно когда оно осуществлено не человеком а «роботом выполняющим регламентную операцию». в Досье робота?

Если факт имеет отношение к Иванову, то пишем к Иванову.
В реальной жизни как. Вам выдают на руки бумажку где написано, что Петров выдал вам кредит. А у Петрова написан дубль, что Петров разрешил Иванову выдать кредит. И это нормально.

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

РДБМС проектировалось в 80х годах. Сейчас, если ничего не напутал, 2014. Даже если у вас будет досье в среднем по одному мегабайту (что очень много для текстового формата) на каждого пользователя, то на одном винте за 120$ можно разместить инфу на 3 млн пользователей. А если применить сжатие, то не менее чем на 30-50 млн пользователей.

Записи в досье сущностей — это не позволяют. всякое действие — «фулскан»

Есть полнотекстовый индекс по досье. Он работает очень быстро, намного быстрее чем джоины по таблицам.

Если факт имеет отношение к Иванову, то пишем к Иванову.
факт имеет отношение еще и к учреждению где Иванов получил кредит.
И наверняка к автосалону где Иванов собрался покупать автомобиль.
В реальной жизни как.
основная масса проектов в которых участвовал, на разных ЯП и системах именно такие, из реальной жизни. что-то там лет 15, из 20ти.
РДБМС проектировалось в 80х годах. Сейчас, если ничего не напутал, 2014. Даже если у вас будет досье в среднем по одному мегабайту
событий гораздо больше чем количеств досье.
перед внесением данных — обычно нужно проверить их корректность.
а для этого — обработать часть событий.
при этом инициаторов действий будет минимум по количеству операторов системы.
Есть полнотекстовый индекс по досье. Он работает очень быстро
..., если индекс вмещается в оперативную память.

вобщем, вы бы вместо рассуждений(весьма наивных, ИМХО), потратили бы пару выходных, и написали бы свою БД, для классической задачи «склад магазина»:

затем — сгенерировали бы пару сотен поставщиков, пару сотен покупателей, пару тысяч видов товара, и пару десятков тысяч движений по каждому, скажем в первом квартале года. ну там — приход-расход, можно просто количество единиц, без денех.
при этом — система не должна позволять отрицательных остатков ни в какой момент времени, то есть и в момент начала заполнения данными.
и затем — поиграйтесь выборками
сколько было продано за период с дата1 по дата2
в разрезах покупателей, товаров

по группам покупателей, по группам товаром

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

а если их исключить, то когда и по каким?

замерьте время

выложите это дело на гитхаб или битбакет (мне меркуриал симпатичней, может и вам тоже)

вернитесь в тему со ссылкой.

..., если индекс вмещается в оперативную память.
вобщем, вы бы вместо рассуждений(весьма наивных, ИМХО), потратили бы пару выходных, и написали бы свою БД, для классической задачи «склад магазина»:
затем — сгенерировали бы пару сотен поставщиков, пару сотен покупателей, пару тысяч видов товара, и пару десятков тысяч движений по каждому, скажем в первом квартале года. ну там — приход-расход, можно просто количество единиц, без денех.
при этом — система не должна позволять отрицательных остатков ни в какой момент времени, то есть и в момент начала заполнения данными.
и затем — поиграйтесь выборками
сколько было продано за период с дата1 по дата2
в разрезах покупателей, товаров
по группам покупателей, по группам товаром
когда было наибольшее значение остатков на складе.
по каким товарам?
а если их исключить, то когда и по каким?
замерьте время
выложите это дело на гитхаб или битбакет (мне меркуриал симпатичней)
вернитесь в тему со ссылкой.

С РДБМС морочится мне лень :)
Там это дело делается не то чтобы сложно, но если делать все «по уму», то таблиц 30-40 по минимуму нужно. Соотвественно количество процедур в два раза больше, в среднем.

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

Всего товаров на всех складах:
booben.com/Net?tags=test

Обувь на складах в Киеве
booben.com/...?tags=test,киев

Обувь на складах в Харькове
booben.com/...gs=test,харьков

Количество кроссовок на всех складах
booben.com/...=test,кроссовки

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

С РДБМС морочится мне лень :)
я о текстовом варианте, с индексатором.
Там это дело делается не то чтобы сложно
конечно. да и на текстовых файлах-досье — тоже.

если бы я верил в эту идею — сделал бы сам. в качестве исследования.
тем более что и примеры есть. видел как-то для node.js базку что просто — накапливает все записи в одном файле, то бишь на запись — шустра.
выборки — тоже есть, «кортежи» там в jsonе.
а если еще и разносить записи по какому-то признаку типа, в разные файлы, то и ...

В документоориентированой базе все немножко проще
да, на Lotus Notes умельцы ваяли и бухглатерии :)

но я не увидел в примерах

booben.com
решения простейшего случая склада, что предложил
Обувь на складах в Харькове
сайт обрабатывает движения по всем складам Харькова? ;)
как он получает — остаток на дату?
решения простейшего случая склада, что предложил

Какой именно запрос интересует ?

топ 5 товаров по продажам, за первую неделю августа.

топ 5 покупателей за вторую половину августа.

какие из товаров первого топ 5 оказались в списке покупаемых у второго топ 5

Если по мере ведение базы данных вести такое «Досье Топа»

Иванов (Кроссовки:10 штук, Треники 5 шт, Шапка 4 шт)
Петров (Буцы:1 штук, Шарф 4 шт)
Сидоров (Кроссовки:10 штук, Треники 4 шт)

Итого
Кроссовки 20 штук
Треники 9 штук
Шапка 4 штука
Буцы 1 штука
.....

То получаем два плюса.
+ Отчет на любой обьем данных возвращается «моментально»
+ Храним историчность изменения топа

Минус
— Все запросы нужно знать заблаговременно.
— Если запрос не знать заблоговременно, фулскан и подсчет

Если по мере ведение базы
по выборке — база крохотная.
Отчет на любой обьем данных возвращаются «моментально»
OLAP средства, или такие как QlikView — тоже дают «моментальные» отчеты.
только им нужны — структурированные таблично данные.
а не — «досье» с данными разных «типов».

то есть, тогда вопрос второй — так

booben.com
 — это всего лишь report system?

что у нее с ACID и конкурентным доступом на запись-чтение?

Минус
ну так эти минус был известен еще до появления RDBMS
ответом на них и было появление — RDBMS

была такая БД — ru.wikipedia.org/wiki/MUMPS
я на ней писал.
Памяти ей нужно — смешное количество. в сравнении с RDBMS с индексами, или индексу по текстовым файлам
и много других преимуществ

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

вообще, для меня движение NoSQL часто выглядит как второе пришествие MUMPS, либо — а я хочу хранить документы! (будто документоориентированные БД нечто ранее неизвестное)

за исключением таких БД как Cassandra. то есть AP класса. Вот эти БД решают задачи которых раньше не было, и поэтому никто и не разрабатывал БД для решения таких задач.

минусы — ручное написание выборок данных.
если какая-то выборка не предусмотрена, то можно нарваться на аналог «фулскана»

Как будто на SQL все в автоматическом режиме и на фулскан нереально нарваться. Нет курсоров и вообще не существуют отчетов, которые строятся по пол часа и более. На то она и аналитика, что требует времени и дополнительных приседаний. Если она не предусмотрена ранее.

а я хочу хранить документы! (будто документоориентированные БД нечто ранее неизвестное)

Я эту тему поднял в контексте того, что документоориентированые базы намного проще в поддержке, проще масштабируются, более интуитивно понятны, более компактно хранят данные и могут поддерживать историчность данных и другие плюшки «из каропки».

А на РДБМС вроде сначала все красиво, но потом вдруг выясняется что в базе уже 500 таблиц, 1000 процедур и 80% таблиц служебные. А все могло бы хранится в понятных документах/досье.

Как будто на SQL все в автоматическом режиме и на фулскан нереально нарваться.
реально. лечится — настройкой индексов.
иногда — переделкой некоторых запросов.
затраты на такое лечение — мизерны в сравнении с NoSQL
Я эту тему поднял в контексте того, что документоориентированые базы намного проще в поддержке,
для хранения документов — естественно. они для этого и предназначены :D

MongoDB — ай красава!
А складской учет в ней вести?

А на РДБМС вроде сначала все красиво, но потом вдруг выясняется что в базе уже 500 таблиц, 1000 процедур и 80% таблиц служебные. А все могло бы хранится в понятных документах/досье.
ну как переведете систему с такой БД на документоориентированную — тогда и поговорим про «могло бы храниться» с намеком — и это лучше!
вы попробуйте на документо-ориентированный БД только целостность бизнес транзакций на изменение обеспечить, при конкурентном доступе ;)

P.S.
Да, кстати, я еще и на xDB писал немного.
Для «досье», — тоже вполне годная штука
community.emc.com/...ity/edn/xmltech

лечится — настройкой индексов.

Не все лечится настройкой индексов. Бывает моменты когда like ’%...%’ и приехали. Нужно докручивать костыль. Или даже не так, когда использование индексов менее эффективно чем фулскан. Да, бывает и такое.

MongoDB
Я про МонгоДБ не говорю, он затачивался под веб и не хранит историчность и другие фишки для энтерпрайза
ну как переведете систему с такой БД на документоориентированную — тогда и поговорим про «могло бы храниться» с намеком — и это лучше!
вы попробуйте на документо-ориентированный БД только целостность бизнес транзакций на изменение обеспечить, при конкурентном доступе ;)

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

Я видел базы данных, которые на РДБМС будут просто похоронены. Из-за этих служебных колонок. При пустяковой модели данных, реализация просто усложнилась многократно.

Бывает моменты когда like ’%...%’
у-у-у, как все запущено :)
про Full-text индексы — не слышали?
и не хранит историчность и другие фишки для энтерпрайза
повторюсь — в нем и живу, в энтерпрайзе этом.

историчность — стопицот раз решенная проблема.

и второе — а как вы ее бытенько предлагаете решить на NoSQL БД? без фулскана?

На Мумпсе разве мало всего было написано ?
много. До сих пор работают системы на нем.
Нужно просто сесть и доточить нормально, сделать высокую абстракцию над данными, чтобы избавится от служебных колонок.
ну так чего ж не доточили? ;)

может все же прочтете «рекламные статьи» 80ых о преимуществах реляционных БД?

Я видел базы данных, которые на РДБМС будут просто похоронены.
я чаще видел как РДБМС хоронили иные базы :)
и MUMPSовские в том числе.
При пустяковой модели данных
пустяковые модели бывают разве что в пустяковых задачах.

и это точно — не в мире энтерпрайза.

у-у-у, как все запущено :)
про Full-text индексы — не слышали?

Я же сказал — костыль. Из-за того что РДБМС не может нормально работать по таким колонкам, докручены отдельные пристройки с боку, чтобы хоть както нивелировать эти проблемы.
Часто от сторонних вендоров.

ну так чего ж не доточили? ;)

Дотачивают. Крупные вендоры одни за одним послезали с РДБМС. Или сидят там частично.

пустяковые модели бывают разве что в пустяковых задачах. и это точно — не в мире энтерпрайза.

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

Крупные вендоры одни за одним послезали с РДБМС.
это какие?
гуглы с амазонами которым изначально нужна была горизонтальная масштабируемость, причем НЕ для задач энтерпрайз типа?
Нет, пустяковые модели бывают там, где задачу не усложняют
понятно. я вас услышал:
«предметную область всегда можно упростить»

наивность не порок.
но точно об энтерпрайзе вы мало что знаете.
на том и закончим.
пустословие сплошное, как выясняется, «пороху не нюхавшего» :)

вы попробуйте на документо-ориентированный БД только целостность бизнес транзакций на изменение обеспечить, при конкурентном доступе ;)
На сколько я понимаю, то есть для этого решения, определенные классом NewSQL решений, которые пропагандирует, как более перспективную альтернативу NoSQL решениям — Michael Stonebraker (один из основных разработчиков Ingres и PostgreSQL).

Как Вы думаете, Серёжа, действительно ли можно было бы использовать, например из NewSQL решений, — VoltDB для закрытия проблем, которые проявляются при игнорировании некоторых (всех) из ACID принципов? Пробовали ли Вы NewSQL? Или слышали может что-нибудь об этом интересное?

ACID это головная боль в основном RDBMS. Потому что там где обычная документоориентированая база просто редактирует эксклюзивно документ, по схеме Один документ = Один поток, то RDBMS пытается редактировать 20 таблиц одновременно с разных потоков.

ACID это головная боль в основном RDBMS
ACID — это требование энтерпрайз мира.
Потому что там где обычная документоориентированая база просто редактирует эксклюзивно документ
а изменения нужно сделать в нескольких документах.
ведь вы же предлагаете дублировать информацию в разных «досье»?
то есть придется блокировать ВСЕ документы даже на — чтение.
RDBMS пытается редактировать 20 таблиц одновременно с разных потоков.
зависит от того как спроектирована схема.

и я не пойму, вы постоянно говорите о блокировке 20 таблиц.
вы не слышали о строчной блокировке?
а о версионировании транзакций — тоже не слышали?

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

а изменения нужно сделать в нескольких документах.
ведь вы же предлагаете дублировать информацию в разных «досье»?
то есть придется блокировать ВСЕ документы даже на — чтение.

Это какаято очень сильная магия. Обьясните, почему при чтении дублей их нужно блокировать ?

и я не пойму, вы постоянно говорите о блокировке 20 таблиц.
вы не слышали о строчной блокировке?
а о версионировании транзакций — тоже не слышали?

Проблема в том, что документоориентированой СУБД нужно всеголишь проверить и заблокировать root документа. Читайте — несколько машинных комманд. А РСУБД прийдется постоянно морочится с блокировками, она может одновременно управлять сотнями блокировок, поскольку в одну таблицу сразу может быть несколько писателей. Отсюда же и понятно почему документоориентированные базы лучше горизонтально масштабируются. Они просто имеют гораздо меньше шареных ресурсов.

Вам пора бы назвать эту чудесную БД.
Вы так уверено говорите что кажется у вас серьёзный практический опыт.
Так о какой БД вы говорите?

Есть мнения что на сегодня это одна из самых турбированых СУБД. Просто бенчи не хватает рук дописать на остальные СУБД в этой весовой категории вроде Беркли и Токио кабинет. Всетаки вставка\чтение 80 млн 32х битных рандом ключей за 4 секунды в один поток поражает всякое воображение :)

Чье воображение поражает?
Это как мерять ЯП по скорости сложен в цикле до миллиарда
Или серверное решение по количеству отдаваемых строк Hello по http запросу GET

Такая скорость востребована в основном на embedded нагрузках. Ну например индексируется контент и улетает несколько миллиардов запросов в час к внутренней СУБД. Или что-то архивируется, идет очень быстрый поиск токенов.
Если такую мощь посадить на http, то конечно 99.99999% времени будет простой.

А что поражает? Без каких-то условий, что там происходит еще, в моем воображение 80 миллионов 32-х битных значений гораздо быстрее обрабатываются )) Для ничего неделания 4 секунды — просто вечность.

Я просто не в курсе, что то за субд и какие задачи решает. Какую работу нужно сделать, чтобы что-то куда-то вставить или считать, какие транзакции

Всетаки вставка\чтение 80 млн 32х битных рандом ключей за 4 секунды в один поток поражает всякое воображение :)
Тю, даже тормозная джава с приблизительно такой скоростью работает:
    Random r = new Random();
    Int2IntOpenHashMap map = new Int2IntOpenHashMap(); 
    for (int i = 0; i < 40000000; i ++) {
      int num = r.nextInt();
      map.put(num, num);
    }
4.8sec

"не верю"©
У тебя в цикле еще

r.nextInt()
замеряется. Попробуй его убрать из цикла.
    Int2IntOpenHashMap map = new Int2IntOpenHashMap(80000000); 
    for (int i = 0; i < 80000000; i ++) {
      map.put(i, i);
    }
4081ms

Код я выложил, возьми сам попробуй.

Не. Тебе надо сделать рандом ключи, но не тратить времени на их генерацию. У меня джавы нет на машине, но дот нет, который кстате побыстрее чуток джавы будет, успешно слился
Вот тут есть бенчмарк.
www.sql.ru/...s/stebelek/1269

Random r = new Random();
    int nums[] = new int[80000000];
    for (int i = 0; i < 80000000; i ++) nums[i] = r.nextInt();
    Int2IntOpenHashMap map = new Int2IntOpenHashMap(80000000);
    long t1 = System.currentTimeMillis();
    for (int i = 0; i < 80000000; i ++) {
      map.put(nums[i], nums[i]);
    }
    long t2 = System.currentTimeMillis();
    System.out.println(t2 - t1);
Все как ты пожелаешь — все теже 4сек.

Блин, ну ты сравнил хрен с пальцем :))
Тачка у тебя в полтора, ато и два раза мощнее на чем я тестировал:
cpubenchmark.net/...1214&cpuCount=2

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

А у тебя какой проц? Я пробовал Int2IntLinkedOpenHashMap заюзать, которая позволяет делать все что ты рассказал, оно выдает 6сек вместо 4сек.

Я тестировал тогда на iCore7 четырехлетней давности.
Короче у меня на сегодня самая быстрая СУБД в галактике :) Еще она умеет моментально сериализироваться и десирализироваться с\на диск и еще имеет несколько класный фишек.

Ну так Е5 это и есть и7, только в серверном варианте с отключенным интегрированным ГПУ

cpubenchmark.net/...1214&cpuCount=2

Если это так, то почему здесь мы видим другие цифры ?

Потому что там приведены далеко не все и7 процы?

fastutil.di.unimi.it/...penHashMap.html

подыми мне веки.
где там метод, аля getRange(startKey, endKey)

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

А код? Есть уверенность, что он одинаковый? Ведь одинаковая по интерфейсу структура данных совершенно не факт, что такая же внутри. В дотнете лень сейчас открывать, но любят пользоваться сплошными массивами, и списки там — массивы. Так что Dictionary<> вполне может иметь ссылки на массивы. Которые время от времени стают маленькими и начинают копироваться. В джаве вполне вместо них могут быть связные списки. Я не в курсе, что в джаве. А может вообще красночерное дерево.

Ну я так понимаю что тут и происходит меряние структурами данных, бубен рекламирует свою ВымяДБ с уникальными алгоритмами внутри

заглянул в дикшинари дотнетовский. Занятно. Связный список внутри выделенного массива.
Может и в джаве подобный, может и нет.

Блин, еще совсем забыл. Короче твой генератор рандома в тесте УГ. В смысле там если делать с умом, то нужно более сложный генератор «белого шума». Этот который стандартно идет в либах, он никудышный, имеет периоды и неравномерное распределение. На них хештаблицы быстрее работают.

вот оно что, генератор не той системы оказался..

да с джавой таже история что с дот нетом.
А на дотнет я тебе бенчмарки приводил.

На .нет не видел, видел на ц++, где ты как то странно std:map заполняешь

Да, всегда знал что .нет тормоз

Он не тормоз, джава больше тормозит.
Просто у тебя машина помошнее.
Вот есть еще тесты для GLib для любителей Linux
wiki.pikosec.com/...Lib::GHashTable

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

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

А, т.е. из того что джава уделала ВымяДБ, ты сделал вывод что у меня машина мощнее. Логика, че.

Где уделала, тыкни какой тест ?
Для последовательных ключей вообще почти на порядок отстала. Для рандома будет отставание минимум в два раза.

Ну у типичного и7 частота 3.4ГГЦ, у моего ксеончика 2ГГЦ, т.е. он работает на одном потоке в полтора раза медленнее, моя прожка справилась за такое же время как твоя на в полтора раза более медленном проце, значит она в полтора раза быстрее.

Еслибы все было бы так просто, то какой нибудь разогнаный Целерон десятилетней давности заруливал твой ксеон :)
Там от многих факторов зависит, в частности от кеша проца. Я уже скачал джава сдк и эклипс, щас разбираюсь, щас потестируем

Ну на однопоточной прожке может и заруливает, у меня ж не суперкрутой ксеон, тоже старье в принципе.

Как эту хрень подключить ?
Через нейспейсы эклипс не определяет. Это надо какойто пакет подключать ?
Int2IntOpenHashMap

Нужно джарник с интернета скачать

У вас даже не мавеновский проект? шо за позор!

У меня гредйл, посыпаю голову пеплом.

Ну от. Шо и требовалось доказать :)
Щас у меня ноут i5, но тем не менее
На 80 млн к сожалению слетает с аут оф мемори.
Но базовый твой примерчик с рандомом для 40 млн отрабатывает за 4.3 сек. Тоесть 80 млн будет все 10 секунд.

Так ты ж сам написал что в базовом примере рендом внутри считается и типа не катит

Я второй пример использовал твой.

Вот
import java.util.Random;

import it.unimi.dsi.fastutil.ints.Int2IntOpenHashMap;

public class HelloWorld {

public static void main(String[] args) {
// TODO Auto-generated method stub

Random r = new Random();

int nums[] = new int[20000000];
for (int i = 0; i < 20000000; i ++)
nums[i] = r.nextInt();

Int2IntOpenHashMap map = new Int2IntOpenHashMap(20000000);

long t1 = System.currentTimeMillis();

for (int i = 0; i < 20000000; i ++) {
map.put(nums[i], i);
}

long t2 = System.currentTimeMillis();
System.out.println(t2 — t1);

}

}

Короче это самое.
Замерял я. Как и предполагалось, генератор УГ.
На Си я переделал и теперь так заполняю рандом.
intKeys[i] = rand()
Полностью по аналогии с джабой.

Короче говоря. 20 млн рандом ключей.
ВымяДБ = 0.185 секунд
Джава = 1.7 секунд

А есть какие нибудь простые инструкции по использованию твоей вымядб под линукс? Чтобы сделать пруфчекинг твоих результатов? Предположим я в Ц++ слабо рублю.

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

Самая продвинутая либа кстати под джаву это mapdb.org, и помощнеe твоей вроде, на досуге потестирую производительность.

На Си я переделал и теперь так заполняю рандом.
intKeys[i] = rand()
Полностью по аналогии с джабой.
НУ может у жабы рандом покруче..

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

Теперь я могу со спокойной душой пойти спать :)
Я уж думал джава действительно из штанишек выпрыгнула, но все оказалось банальней. У хохлов теперь самая высокопроизводительная субд для 32х битных ключей в этом созвездии :D

На Си я переделал и теперь так заполняю рандом.
intKeys[i] = rand()
Полностью по аналогии с джабой.
Короче говоря. 20 млн рандом ключей.
ВымяДБ = 0.185 секунд
Джава = 1.7 секунд
Ну и вот такой код на цпп выдает 0.16 сек на 80млн ключей. СТЛ по прежнему лучший:
#include <map>
#include <stdio.h> 
#include<iostream>
#include<vector>
#include<ctime>

using namespace std;

int main(int argc, char **argv) {
  map<int, int> m;
  vector<int> nums(80000000);
  for(int i = 0; i < 80000000; i ++) nums.push_back(rand());
  clock_t t = clock();
  for(int i = 0; i < 80000000; i ++) m[nums[i]] = nums[i];
  cout << "Time Difference: " << (clock() - t) / (double)(CLOCKS_PER_SEC / 1000) << endl;
}
#include <map>
#include <stdio.h>
#include<iostream>
#include<vector>
#include<ctime>

using namespace std;

int main(int argc, char **argv) {
map<int, int=“"> m;
vector<int> nums(80000000);
for(int i = 0; i < 80000000; i ++) nums.push_back(rand());
clock_t t = clock();
for(int i = 0; i < 80000000; i ++) m[nums[i]] = nums[i];
cout << “Time Difference: ” << (clock() - t) / (double)(CLOCKS_PER_SEC / 1000) << endl;
}

А ты вообще дебажил то что понаписывал ? ))
У тебя 80 млн раз вставляется в мапу “ноль”.

ЗЫ: Чудес не бывает. STL одна из самых тормознутых шарманок.

Вот, я феншуйно переписал.
40 млн ключей = 53 секунды


#include “stdafx.h”
#include <map>
#include <stdio.h>
#include<iostream>
#include<vector>
#include<ctime>

using namespace std;

int main(int argc, char **argv) {
map<int, int=“"> m;

int* nums = new int[40000000];

for(int i = 0; i < 40000000; i++)
nums[i] = rand() * i;

clock_t t = clock();

for(int i = 0; i < 40000000; i++)
{
m[nums[i]] = nums[i];
}

cout << “Time Difference: ” << (clock() - t) / (double)(CLOCKS_PER_SEC / 1000) << endl;
}

Eclipse — кал, поставь уже IDEA. Не придется синхронизировать workspace да и депенденси норм. подтягиваются.

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

Не знаю что автор имел в виду по поводу неравномерного распределения, но периоды могут повысить эфективность использование кеша процессора.

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

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

Я так понимаю, автор ссылается на некий генератор белого шума, который в цикле будет давать числа, у которых у всех (hash % hashtableSize) всегда одинаковый, снизит эфективность работы хеш таблицы.

в цикле будет давать числа, у которых у всех (hash % hashtableSize) всегда одинаковый, снизит эфективность работы хеш таблицы

Ну так, если такая формула дает одно число, это и есть генератор, который дает числа неравномерно, а с периодом, совпадающим с количеством hashtableSize. hash — это ж рандомное его число? Допускаю, что автор сделал опечатку, когда написал, что эффективность будет выше. Но пока он не признает

Т.е. любые комбинации, равномерное распределение — и есть вариант, когда коллизий наименьше.

Примечание: Равномерное распределение после хешфункции.

Всё равно не понятно. Может я слишком занят, чтобы смотреть в ваш код.
Вы, насколько понимаю, генерите инты и пихаете в хеш-словарь. В дотнете, например, сам класс отвечает за возврат хеша. И хешкод всегда интовый. И угадайте, какой хеш-код возвращает инт? Сам себя.
Значит, если будет равномернее распределение интов, быстрее будет работать словарь. Бывает такая хрень, когда хеши не совсем равномерны и желательно их зашумить еще раз. Вот, сомневаюсь, что словарь в дотнете этим занимается.
Но даже если бы занимался, что легче приводится к равномерному распределению, неравномерное или равномерное? Особенно сложный случай, когда часто хеши совпадают. Это уже никак на зашумишь.

Просто поставьте пару экспериментов и приблизитесь к пониманию.

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

да кто ж спорит, что фундаментальные. Но не значит, что одинаковые.
И с чего вдруг там ассемблер или Си. В управляемом коде.

Всё там нормально. Матерые дядьки и на дотнете пишут, не только на ассемблере ))

Вот тут есть бенчмарк.
www.sql.ru/...s/stebelek/1269
И в чем там состоит слив дотнета?

Для последовательных ключей, как ты видишь джавовская балалайка работает почти в 10 раз медленее чем моя структура данных. 0.3 сек против 4сек у джавы.
+ Какбе у меня ключи отсортированы, можно по диапазонам получать. А в джавовской хештаблице — нет.

Пока что о абстрактной БД. То что я писал, делалось конкретно для поисковика. Для индексирования и поиска на массивах в многие терабайты. А сейчас я потихоньку собираю пазл для энтерпрайза. Просто ковыряю потихоньку теорию. РДБМС кстате тоже с этого начиналась.

Я так и понял.
Дерзайте. Чтобы зря не тратили время я вам уже предложил простое исследование.
Вы что, не можете на джаве, шарпе, да хоть питоне написать приложение работающее с текстовыми файлами, поставить какой-нить Solr и принимать отдавать по TCP строки?

Энтерпрайз оставьте. Никто с таким уровнем вашему пазлу не поверит. Вы понятия не имеете что действительно там является проблемами. Решение ваших личных проблем энтрепрайзу и с доплатой не нать. Поэтому и не понимаете почему давно известные документоориентированные БД не используются для типичного класса задач.

>>Это какаято очень сильная магия. Обьясните, почему при чтении дублей их нужно блокировать ?

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

Это исторические дубли, они не блокируются. Более того, если одни запросы читают историю, то они не мешают тем запросам, которые читают актуальные данные.

Я вообще про денормализованные «вширь» схемы говорил, типа ФИО клиента в десятке «коллекций документов», ну да ладно.

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

у RDBMS главная на сегодня проблема — горизонтальное масштабирование.
которую NewSQL решат с помощью — in-memory database

то есть — если нет памяти размером с данные (пользовательские плюс служебные) то в сторону NewSQL можно и не смотреть :)

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

NoSQL базы обычно применяются там где — много конкуретных подключений, в основном на чтение, причем простых срезов.
На изменение — тоже простое.

NewSQL — это когда и жирные и много подключений.

А сколько обычно рабочих мест нужно в корпорации? пара сотен. редко — тысяч. для одного отдела.
Нужно для этого тратиться на поддержку железа с NewSQL? общего ответа нет, зависит от конкретных потребностей пользователей.

о есть — если нет памяти размером с данные (пользовательские плюс служебные) то в сторону NewSQL можно и не смотреть :)

А какая разница RAM, SSD или HDD к теории хранения информации ?

Кажется Дейкстра сказал
Учёные из computer science знают о компьютерах столько же сколько астрономы о телескопах.
Судя по вопросу вы учёный? А чего вас занесло рассуждать о презренном в академических кругах корпоративном софте и технических проблемах?

Почему ученный. Просто если работаешь с одним инструментом 10+ лет, уже начинаешь видеть некоторые недостатки в нем. А Вы не видите в РСУБД серьезных недостатков ?

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

Так что давайте лучше о вашей идеальной бд. Сказки полезны.

А мне кажется это у вас какойто наивный взгляд на реляционки и энтерпрайз. Как будто вы ничего тяжелее вебмагазинчика на РСУБД не видели и не знаете в каком они обычно виде.

Мдя...
Это не лечится...

И мне говорят что я не прав когда по трём постам делаю выводы об уровне человека. Вот, пообщался. Не обращая внимание на вопиющую некомпетентность. И оказалось... Дите и в других видит только себя

Вам сначала нужно разобраться с темиже блокировками. Чтото попробовать написать. Покрутить, понять как оно устроено под капотом. Что сколько стоит, какие приимущества, какие недостатки. Почему что-то появилось в РСУБД, почему документоориентированые лучше горизонтально масштабируются. И так далее так далее ....
Я вас не виню, сейчас мало специалистов которые действительно именно понимают матчасть. Вот вчера один из США замерял вставку одного ключа «0» в хештаблицу 80 млн раз. И вот с такими людьми приходится общатся. А вы еще поглупее чем он, судя по фидбекам.

вам вместо того чтобы пустословить и бахвалиться неосведомленностью о мире реляционок и энтерпрайза следовало бы сделать хоть что-то из
— реализовать свои бреды на любой документо-ориентированной СУБД
— написать очередную «dirty DB»
— привести примеры запросов на идеальном языке запросов к идеальной СУБД

замерял вставку одного ключа
вы асилили работу с хэштаблицами и возомнили что поняли как перевернуть мир СУБД? Вы не слышали ничего о key-value хранилищах, и решили наконец изобрести Первое в Мире?
Покрутить, понять как оно устроено под капотом.
я не увидел что вы крутили что-то кроме «эмбедед хранилища» на хэш-мапе
И вот с такими людьми приходится общатся.
да, ужас. вылупились из мира знатока оптимизаций вставки ключа, и опа, а мир то оказывается сложный.
Но «все сложное можно упростить!». аха. кто не пробовал — уверен что это проще пареной репы.

попробуйте хоть раз. и покажите что получилось.

вы асилили работу с хэштаблицами и возомнили что поняли как перевернуть мир СУБД? Вы не слышали ничего о key-value хранилищах, и решили наконец изобрести Первое в Мире?

Знаете, Вы мне напомнили Остапа Бендера, в Васюках:


Если бы Остап знал какие мудреные партии он разыгрывает, то очень бы удивился. Дело в том, что великий комбинатор играл в шахматы второй раз в жизни © 12 стульев.

Вот и про хештаблицы вы даже не представляете НАСКОЛЬКО это сложная задача. И почему за 50ти летнюю историю хештаблиц, только за последние пять лет были изобретены наилучшие хешфункции, вроде тогоже мурмур хеш.

Вот и про хештаблицы вы даже не представляете НАСКОЛЬКО это сложная задача.
а мир бизнес ПО да, проще некуда :D
все то вы знаете о нем, те кто хэши оптимизируете :)

Мир бизнес ПО действительно проще. Потому что существует овер 10 млн индусов которые умеют «кодить» на sql и накодят все что угодно. Правда потом прийдется купить помошнее сервер и увеличить штат в два раза, но то такое ...

да, да, только вам почему-то и 0,0....1% от сэкономленных вашими идеями средств не дадут.

но вы пробуйте, дерзайте.
вернитесь в 70ые и — ваяйте на C бухгалтерские системы. на хэш-мапах.
у вас все получится!

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

А могло бы быть все как досье. Вот она папка о «Иване Иванове», здесь есть всё. Его биография, кредитная история, штрафы за поездки. И не нужно 1500 ящичков по всему архиву.
С одной стороны — удобно. Но мало кому нужно знать об «Иванове» все-все сразу. Медицинская карточка нужна только врачам, но кредитная история или трудовая книжка им без надобности. А ведь все хранится вместе.
И еще часто возникает задача найти какого-нибудь «Иванова» по определенным критериям (например призывников) — и придется поднимать все досье и рыться.
В реальной жизни информация о человеке то же не хранится в одном месте — она хранится ближе к тому, где нужна (карточка в поликлинике, трудовая на работе и т.д.). Естественно, возникает необходимость делать «выписки», получать справки из одного места для показа в другом и т.д. Это обратная сторона.
Информация не может храниться вся в одном месте и одном экземпляре — это не удобно. Она должна быть доступна там, где она нужна. Но с другой стороны информация не должна храниться хаотично и быть противоречивой. Поэтому невозможно создать универсальную систему хранения, которая бы удовлетворяла всем критериям.
Это наша задача — разобраться какую информацию как и где лучше хранить и какие технологии для этого использовать. Не выбрать одну готовую систему (NOSQL или RDBMS) и пытаться «подогнать», а именно выбрать технологии под задачу.
Справедливости ради надо сказать что кроме NOSQL и RDBMS есть и другие решения. Например Event Sourcing : martinfowler.com/...ntSourcing.html . Так что выбор точно не из двух альтернатив.
Но мало кому нужно знать об «Иванове» все-все сразу. Медицинская карточка нужна только врачам, но кредитная история или трудовая книжка им без надобности. А ведь все хранится вместе.

В данном случае — одна информационная система = одно хранилище. Тоесть кредитная история Иванова и его Медицинская карточка не будут хранится вместе, поскольку скорей всего это будут две независимых системы. Но в рамках медицинского центра или банка, вся информация о Иванове должна хранится в одном досье. Так удобней. Причем в этом досье должни быть дубли, должна отслеживаться история этого досье.

А РДБМС это достаточно неудачно. Чтобы получить базовую информацию о Иванове, нужно наджойнить с двадцаток таблиц. Всё лежит в разных углах. История по умолчанию не отслеживается. Логи по умолчанию не ведутся. Транзакция приводит к блокировке сразу нескольких таблиц, а не одного досье клиента с которым работаем.

А РДБМС это достаточно неудачно.
Это потому — что такие жесткие требования к этой системе поставили. Что бы данные хранились в одном месте, были всегда непротиворечивыми, всегда актуальными и т.д. И при этом что бы разные пользователи одновременно меняли разные куски данных, но не возникало конфликтов.
И это работает именно так, как задумано. Так почему Вы говорите «неудачно»? Наверно потому, что у Вас были совсем другие требования в приоритете. Тогда нужен и подход другой. Например, собрать информацию из 20 таблиц и продублировать в NOSQL.
Всё лежит в разных углах
а никуда не денетесь от углов.
либо раскладывайте сразу по разным углам
либо потом по всем ищите то что было бы разложено в первом случае

«углы» появятся в любом случае
либо сразу, либо на время выборки.

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

От углов можно избавится, если будут дубли. И если выбросить реляции.
Дубли это не зло — это контекст модели данных. Если Иванову однажды выдали «Кредит Выгодный 5%» то он должен лечь в историю как дубль со всеми параметрами кредита и дальнейшая судьба этой кредитной акции уже не важна. Для клиента она выглядела именно так на тот момент когда он получил этот кредит. А РДБС предлагает хранить как реляцию на таблицу «Кредитные акции».

невозможно создать универсальную систему хранения, которая бы удовлетворяла всем критериям.
невозможно имеет смысл заменить на — дорого. И тут стоит учитывать, то сто 20 лет назад было «дорого», сегодня уже вполне может составлять — «копейки».

Не «дорого», а именно «невозможно». Потому что если есть противоречивые требования, то выполнить оба невозможно. Можно или чем-то пожертвовать, или найти компромисс, или разделить на два хороших по-своему.
Например нельзя на месяц написать быструю, надежную и удобную операционную систему. Даже если заплатить очень дорого.

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

А для лучшего оперирования противоречиями рекомендую вдумчиво ознакомиться с методиками мышления из теории ограничения Голдратта, раширяет горизонты.

Хорошо, если время то же считать ресурсом — то да, «дорого». Можно смело утверждать что нет такой задачи, которую невозможно было бы решить за бесконечное время.

По второй позиции

docs.oracle.com/....htm#VLDBG14127
Using Temporal Validity

docs.oracle.com/...gn.htm#ADFNS967
1.9.4 Temporal Validity Support

Вендоры о этой проблеме знают (они не могут не знать) и предлагают свои решения «с боку реляционки». Да, каждый частный случай решается своими костылями. Но нет комплексного решения. Решения которое сделает высокоуровневую абстракцию из данных, а все служебное, весь tracking, approve, status вынесет за скобки и спрячет гдето в недрах движка.

Что касается принципа RDBMS «изменения нужно вносить только в одно место», то зачастую, как не странно, оно противоречит современным требованиям бизнесса.

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

У нас простая и логичная модель данных
у вас денормализированная и неправильная модель данных нарушающая уже первую НФ.

Если она будет в адекватной НФ данные будут обновляться в одном месте.

Вообще-то RDBMS не накладывает такого требования. Это не более чем идеология, уверяю. Скажу больше — ваша собственная память устроена иначе, и одну и ту же инфу вы храните одновременно в нескольких местах. Это позволяет мозгу, работающему с частотой (задумайтесь) всего лишь до 150Гц оперировать с объектами от которых зависит жизнь, например управлять автомобилем.

Так что не преувеличивайте значение реляционки. Вся её суть — именованные массивы данных и отношения между ними. И первое же, что выделаете при проектировании — это СВОИ ИНДЕКСЫ, которые как-то хитрожопо спрятались от теории. Потому что они нарушают теорию! Де-факто индексы являются ЕЩЁ ОДНИМ хранилищем информации, дублирующим. И да, при вынуждены обновляться синхронно. А при повреждении индекса — вы наверняка завалите инфу в базе.

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

Приведу пример: вы в интернет-магазине выписали счёт. И отправили на проплату. За это время, пока клиент оплачивает, цена товара поменялась на 10 копеек, к примеру из-за курса долара. Что вы будете делать — кричать «произошла ошибка, разбирайтесь как хотите»? Или таки продумаете ДУБЛИРОВАНИЕ товара, фиксируя все данные на момент начала транзакции?

Или таки продумаете ДУБЛИРОВАНИЕ товара, фиксируя все данные на момент начала транзакции?
MS SQL Server за вас это делает в режимах SNAPSHOT и READ COMMITED SNAPSHOT.
MS SQL Server

Это блокировочник (а не версионник). Обычно он просто блокирует запись. Тоесть физически дубля нет.

Это блокировочник (а не версионник). Обычно он просто блокирует запись. Тоесть физически дубля нет.
Вы хотя бы обратились к гуглу для начала если не работали с MS SQL. Вот мой пруф msdn.microsoft.com/...y/tcbchxcb(v=vs.110).aspx

Спасибо за ссылку. Я начинал работать с MS SQL 2000, похоже это уже отдельный версионный костыль докрутили для версий выше 2005. Он отдельно включается настройкой
SET ALLOW_SNAPSHOT_ISOLATION ON.

Enter optimistic locking. SQL Server 2005 introduced two new isolation levels to help you in your mission towards ever greater concurrency: SNAPSHOT and READ COMMITTED SNAPSHOT isolation

это СВОИ ИНДЕКСЫ, которые как-то хитрожопо спрятались от теории
именно.

везде на ЯП так — в профессиональном коде одновременно описана и какая-то теория и инженерная реализация.
В теории не существует временных затрат на выборку подмножества из множества по какому-то критерию.
поэтому там и индексов нет :)
а уж анализ плана запроса RDBMS... для математика ужас действительнсти :)

Скажу больше — ваша собственная память устроена иначе, и одну и ту же инфу вы храните одновременно в нескольких местах. Это позволяет мозгу, работающему с частотой (задумайтесь) всего лишь до 150Гц оперировать с объектами от которых зависит жизнь, например управлять автомобилем.
Но при этом позволяет забыть куда вчера положил ключи от машины!
Вот поэтому человек и не хранит всю нужную ему информацию в памяти — ему приходится делать записи. Особенно если информация важная и должна быть точной. А если информации много — то еще и упорядочивать эти записи, делать «оглавление».
Как лучше хранить информацию зависит только от того — какая это информация и как она используется. И исходя из этого уже выбирать технологию.
А если использовать RDBMS так:
И на самом деле, если послать к монахам теоретиков-бюрократов, оказывается что использовать можно всю мощь базы. В частности, дублировать инфо в таблицах, связывать отношения постфактом, иметь различные версии данных внутри одной базы, позволять себе дублирование и вообще творить в точности то же самое, что делает человек при работе с информацией.
то это все равно что использовать лоб для раскалывания орехов.

Теоретически — можно. Практически — я часто раскалываю их руками. Хотя в теории... но теоретики сидят без орехов :)

Если она будет в адекватной НФ данные будут обновляться в одном месте.

Так в этом и логическая ошибка есть. Если мы поменяем адресс магазина, то получится что старые заказы привязаны к магазину уже с новым адрессом. Получается мы не сможем из базы получить информацию, по какому действительно адрессу произошла сделка. И тут есть два выхода. Или делать историчность таблицы «магазины». Или вместе с заказом хранить адресс по которому была произведена эта сделка.
Но можно решить задачу и комплексно. Если бы база сама по себе «аппаратно» хранила историчность, то модели данных значительно бы упростились.

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

Покажите как сделать нормальную схему данных, без оверхеда.

Нормальная схема в вашем случае дающая возможность обеспечить ссылочную целостность делается вынесением адресов в отдельную таблицу в первую очередь.

Что касается конкретной задачи хранения истории и оптимизации.
Ведение истории обычно делается путем создания DWH базы и использования там SCD(Slowly changing dimension) для сущности «магазин» и инкрементальным или snapshot заполнением таблиц фактов. Таким образом весь срез истории уходит в отдельные таблицы, если вы захотите еще и историю редактировать, и это не будет проблемой, так как бизнес ключи будут соответствовать текущему состоянию ключей в основной базе.

Нормальная схема в вашем случае дающая возможность обеспечить ссылочную целостность делается вынесением адресов в отдельную таблицу в первую очередь.

Эта заплатка из разряда "Ну всё, я починил!«©

Что касается конкретной задачи хранения истории и оптимизации.
Ведение истории обычно делается путем создания DWH базы и использования там SCD(Slowly changing dimension) для сущности «магазин» и инкрементальным или snapshot заполнением таблиц фактов. Таким образом весь срез истории уходит в отдельные таблицы, если вы захотите еще и историю редактировать, и это не будет проблемой, так как бизнес ключи будут соответствовать текущему состоянию ключей в основной базе.

А эта вещь уже интересней, но как не странно она тоже является определенным костылем.
Если будет задача, что этот новый магазин будет введен в эксплуатацию с 1января 2015 года в автоматическом режиме, как это решить через DWH ? Получится проблема близнец требующая служебные колонки с историчностью.

Эта заплатка из разряда "Ну всё, я починил!"©
это еще иногда называется нормализация БД и создание схемы данных.
А эта вещь уже интересней, но как не странно она тоже является определенным костылем.
Это задача, которая решается добавлением атрибутов к сущности. Тоже на этапе проектирования бд и создания схемы данных.

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

Например так. В каждую таблицу к первичному ключу добавляются две колонки — даты, начало и конец действия. А все внешние ключи всегда висят на часть ключа, без дат. Запрещено менять значения в строках, т.е. при апдейтах делаете копию строки и изменяете нужные колонки. Добавляя дату завершения в предыдущую строку и дату такую же в новую (мелкий оверхед, чтобы еще ордербаи каждый раз не писать или что-то вроде того).
И всё работает, в запросах только указываете даты и проверяете на больше меньше.

Это всё, конечно, не очень удобно. Но смотрите с другой стороны. СКОРЕЕ ВСЕГО у вас ошибка вообще в архитектуре, если требуется историчность. Глюк какой-то произошел. Есть операционная деятельность, бывают также хранилища данных. Обычно реляционки используются для операционной деятельности. Обычно, это такой конечный автомат, не помнящий истории. Вы посмотрите в свои требования, скорее заказчик мешает коней и свиней в одном зоопарке. Бывает работа, бывает мониторинг этой работы. Это совершенно разные задачи. Не стоит их перемешивать. То, что хочет заказчик — СКОРЕЕ ВСЕГО отчеты. Отчеты — это мониторинг. Также бывает аналитика. Опять же она строится на мониторинге. Так и не надо это делать в одной базе данных. Как я в первом абзаце написал, база с историчностью не имеет права делать апдейты полей, только копии. Если так, то вполне можно сливать в другую базу, часто не реляционку, эти данные. У аналитики другие задачи. Там не надо делать много запросов, не нужны никакие транзакции. Это обычно тяжелые запросы, которые делаются одним/несколькими людьми.

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

Покажите как сделать нормальную схему данных, без оверхеда.

[Щас покажем как надо]

Например так.

[Упс, что-то пошло не так]

Это всё, конечно, не очень удобно

[Но выход есть !]

у вас ошибка вообще в архитектуре

goto step1

Не понял упрека. Я вам показал, как сделать исторические таблицы на реляционке. Что не так?

Оверхед????
щас буду жестко материться, потому как слов нет, часто такую т.з. встречаю.

Писатель когда пишет книгу, он пишет в книге, какую для нее надо бумагу и чернила использовать?
Вы код пишете или что? С хрена вас заботят вещи, не связанные с смыслом, больше, чем смысл кода?
Аналогия с миром идей Платона. Есть идеальный, есть материальный мир. Чертеж поезда (смысл) — это идея. Поезд — это материя. Сам чертеж, бумага, чернила — материя.
Так вот и код должен быть смыслом, а не контейнерчиками и сообщеньицами.

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

Не думайте об оверхеде, пусть субд о нем думает.

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

А NoSQL — это всего лишь бетономешалка: не нравится наш супермаркет (реляционка) — строй сам.

Пофантазирую. Реляционки умирают давно, и всё никак не умрут. Почему? Потому что хорошо себя зарекомендовали. Производительность иногда проблема. Но в каком-то неотдаленном будущем сделают железное решение, которое не будет уступать монгам и прочим. И/или сделают энергонезависимую память не медленнее энергозависимой. Или ОЗУ будет огромных размеров, что реляционки будут помещаться в память с индексами и оптимизациями разными.
В общем, не стоит думать о том, о чем не нужно думать.

Premature optimization is the root of all evil.

Не думайте об оверхеде, пусть субд о нем думает.

Знаете, есть такая хорошая украинская пословица.
"Як постелиш так и будеш спати"©
Ну в смысле хорошая архитектура начинается там, где архитектор хорошо постелил под низ, чтобы наращивать абстракции с минимумом оверхеда.

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

Вы знаете, под реляционными базами данных на самом деле тоже огромный матаппарат. И тоже несколько слоев убрали на уровень движка. Но то что в 80х казалось достаточным, сейчас можно сказать — могло быть и получше.

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

Совершенно не верно. Или вы не поняли идею. Я объяснил, как чисто сделать историчность на реляционной субд. Это никакой не скотч. Неудобства только в написании запросов. Но если выбрать какой-то такой язык поверх SQL, или какие-то табличные функции, чтобы работали оптимально, вместо таблиц, которым передаете время, а если не передаете, то берется текущее — отлично будут писаться и запросы.

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

Неудосбства только в написании запросов.

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

1. Историчность. Данные можно только добавлять. (это рассматривали)
2. Историчность в будуйщем. Это когда какаято сущность вводится в эксплуатацию будуйщим числом. Например сегодня до 12:00 считали так, а завтра после 12:00 система переходит автоматически на новые правила, новые сущности
3. Принцип четырех глаз. Это когда ктото добавил сущность, но она не применяется пока ктото не апрувнит
4. Статусы заявок. Это такая штука, что вроде бы запись одна, но она мигрирует из состояния в состояние. Что есть тоже типом историчности
5. Подробные логи. Это когда у вас произошел инцидент и нужно все восстановить до последнего клика

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

все эти пункты совсем не сюда. Вдумайтесь, тут другая работа с субд: любые изменения объекта — это не изменения объекта, а добавление копии с измененными полями. В базу данных вводится новое измерение — время. И изменяется полностью представление об объектах — это снепшоты изменений во времени.

Допустим вы не вводили время и снепшоты, обычная реляционная структура. Как вы будете вводить сущность будущим числом? Что такое введение сущности? Это инсерт? Вы можете будущим числом сделать инсерт? Без машины времени нет. Так вот, с снепшотами точно так же. Время вводится на уровне инсертов и апдейтов. Благодаря этому вы можете восстановить полностью состояние базы данных на любое время в прошлом, так как будто это была обычная реляционная структура без времени.
Если вас волнует, что меняются сама работа и думаете, что это не реляционная работа, так тоже вроде нет. Просто переформулируется представление об объектах. Один объект — это последовательность его статических снимков во времени. Вы же сегодня вчера на работу не ходили? Вчера вы были один, сегодня другой. При этом сохраняется некоторая общность (которая выражается частью первичного ключа, минус время).

Не совсем так.
В сущности справочники (а список магазинов и их атрибутов — это типичный справочник) не допускают удаления либо изменения именно по причинам историчности.
Если вы перенесли магазин — просто создается новый и блокируются операции на старом. И никакого оверхеда по данным или логике тут нет — запись в справочнике это исчезающий мизер.

Есть оверхед. Поскольку таблица должна будет содержать дополнительную служебную колонку, например, Shop.IsClosed. А лучше ClosedOnDate. И во всех процедурах которые работают с актуальными данными прийдется дополнительно проверять этот флажок.

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

Проблема в том, что если какаято проблема/логика расплывается по всей структуре базы почти ровным слоем, как с служебными колонками, то обычно это говорит о смешивании слоев в архитектуре.

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

А на уровне сиквела никаких уровней нет — он сильно старше этих концепций.

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

Да, совершенно верно.
OLAP — первая попытка выпрыгнуть «в объем». Однако скрещивания ужа с ежом в этих попытках к уверенным результатам не привели в свое время. По многим причинам.
Сейчас окончательно пришло осознание, что для аналитики реляционки не годятся и буйным цветом разрастаются колоночники.
Однако колоночники все еще не годятся для операционной деятельности по причине крайней сложности валидации транзакций и уникальных процедур бекапа и архивации данных.
В другом топике это уже обсуждали и пришли к мнению, что идеальной была бы некая СУБД, в которой можно было бы применять оба подхода. Думаю, что за этим будущее.

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

Возможность получить некие аналитические данные НЕ означает что это было предусмотрено.

Так вот в приведенной схеме таблиц получение данных «покупатель совершал покупки по таким то адресам» — не предусмотрено. оно — случайно так вышло.
а предусмотрено — «покупатель совершал покупки в таких-то магазинах»

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

насчет изменения во времени — то это тоже должно предусматриваться на этапе проектирования.

Более частый пример:
Есть таблица ФИО
Есть таблица Должностные назначения, в которой дата, ссылка на ФИО таблицу, наименование должности.

И на этапе проектирования должен быть задан вопрос:
Должна ли система учитывать что люди, бывает, меняют фамилию?
Есть ли требование к системе — отчет за прошлые периоды обязан выдавать фамилию как она была. а не какая она сейчас.

Причин почему в БД нет автоматической истории значения поля думаю две:
Инженерная — если все поля с историей — обработка выборок из них будет дольше
Теоретическая — и логика и математика слабы в работе со временем. По теории «время» — такой же, равноправный атрибут как и все остальные. В действительности же это особенная характеристика.

Поэтому и приходится проектировать работу с хронологией изменений поля — отдельно. специально предусматривать

Так вот в приведенной схеме таблиц получение данных «покупатель совершал покупки по таким то адресам» — не предусмотрено. оно — случайно так вышло.

Основная задача базы данных, хранить консистентные логически непротиворечивые данные как можно в больших случаях. Да, я согласен, что можно выкрутится и хранить историю. В конце концов и на текстовых файликах можно многое чего построить и предусмотреть. Но историю можно было бы хранить по умолчанию. Подробные логи изменений можно было бы хранить по умолчанию. Также как хранить правила ввода в эксплуатацию новых сущностей в будуйщем. Также как хранить принципы «четырех глаз» для ввода в эксплуатацию сущностей которые апрувят другие пользователи. База данных должна быть высокой абстракцией, которая абстрагирует модель от служебных таблиц. Все это требует современный бизнесс — когда их реляционка вдруг начинает очень сильно разростаться за счет служебных таблиц.

Основная задача базы данных, хранить консистентные логически непротиворечивые данные как можно в больших случаях.
в идеале информацию о всей Вселенной.
ну чтобы можно было сопоставить те же покупки и с лунным циклом.
Но историю можно было бы хранить по умолчанию.
проблема в конечности ресурсов для достижения этой цели «по умолчанию»
Также как хранить правила ввода в эксплуатацию новых сущностей в будуйщем.
да, в идеале нужно предусмотреть все возможные сценарии будущего.
База данных должна быть высокой абстракцией, которая абстрагирует модель от служебных таблиц.
под любой высокой абстракцией будет слой конкретики :)
Все это требует современный бизнесс — когда их реляционка вдруг начинает очень сильно разростаться за счет служебных таблиц.
они все равно — будут, даже если база будет хранить «историю по умолчанию» и «абстрагировать модель от служебных таблиц»

только их будет — еще больше, и без возможности управления ими.

или — для бОльшей части полей такое поведение по умолчанию придется отключать.
например — номер заказа — должен ли иметь историю? а ДатаЗаказа — должна ли иметь историю, ведь в общем случае время ввода в систему заказа и его дата — не тождественны.
и т.д.

в идеале да, и я за то чтобы и про индексы не надо было думать.
и про ограничения памяти вот бы не думать:
дал запрос
выбери мне из населяющих планету Земля людей тех кто живет уже от Х до Y секунд
и в ответ — вот тебе подмножество.

кстати. про индексы приходится думать и в NoSQL базах :D Или проектировать их самому.

«Абстракции текут», когда приходится сталкиваться с эмпирикой.

Я с вами отчасти согласен. Не всем нужна полная информация. Но в случае магазинов, даже если база данных состоит всего из двух табличек, показано что историчность уже не будет лишней. Поэтому, ИМХО, такие служебные механизмы уже должни лежать в самом фундаменте СУБД. Не стоит беспокоиться о обьемах данных. Любая коммерческая СУБД в конце концов идет к реализации этих велосипедов. Просто у одних нет денег на их реализацию, у других есть. А по-хорошему все эти служебные механизмы должни быть вообще вынесены за скобки чистой модели по умолчанию.

Но в случае магазинов, даже если база данных состоит всего из двух табличек, показано что историчность уже не будет лишней.
для случаев магазинов понаписано, понапридумано уже тьма решений.
вплоть до готовых решений в составе ERP систем.
Любая коммерческая СУБД в конце концов идет к реализации этих велосипедов.
ИМХО не из-за удобств программисту, а из-за того что перемещение такого функционала на уровень движка — дает возможность повысить эффективность выполнения запросов.
Не стоит беспокоиться о обьемах данных
..., пока выборки данных происходят за приемлимое время.
А по-хорошему все эти служебные механизмы должни быть вообще вынесены за скобки чистой модели по умолчанию.
да. любая инженерная часть кода должна бы, по хорошему переложена на транслятор.

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

или вообще
Моделирование activity в ISO 15926 — 4D подход
ailev.livejournal.com/1078353.html

а то и положить в основу картинку:
boldachev.livejournal.com/88196.html

Поэтому и приходится проектировать работу с хронологией изменений поля — отдельно. специально предусматривать

вот такая прелесть есть — Travel Through Time with Ease

Эх, неужели нет желающих пораскачивать «священную корову» ?
Люди решают хорошая Катя или плохая, а ты тут с какими-то DBMS.

Кати приходящи и уходящи, а реляционная модель вечна !
Ну или не вечна, тут еще нужно решить.

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

Она ещё дралась с учителем по физкультуре.
Прозвище просто обязывало побеждать.

Эх, неужели нет желающих пораскачивать «священную корову» ? :)

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

В прошлом топике только зацепили верхушку айсберга.
Там рассматривались приимущества noSQL перед РДБМС на специфической задаче.
А здесь я решил промасштабировать на бизнесс задачи.

приимущества noSQL перед РДБМС
РДБМС — сакс, монга рулит, пыщ-пыщ :)

Монга переходящее знамя. Этакий звоночек который существует чтобы Ларри Элисон со своим Ораклом не расслаблял булки. Но как говорится скоро, прийдет тот, кто ... и тут вопросительный знак.

Меня больше интересует сейчас матчасть как следует поковырять.
От части это уже наболевшее. За последние десять лет столько гвоздей реляционками назабивал, что кажется, микроскоп мог бы быть и поудобней :)

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

а, я не заметил, продолжай масштабировать

Думаю попробовать замоделировать стандартный TCP-H тест. Это там где складской учет. Типо 100500 складов, на них 10005000 товара, который проходит по стандартным воркфлоу, привезли на склад, заказали, отгрузили, довезли, выгрузили. И все это крутится на невероятно простой хохло субд. Как думаешь, общественности будет интересен такой тест ?
Или это все будут тесты ниочем, не стоит даже моделировать.
Мне кажется даже на такой нишевой задаче, реляционка может заметно проиграть.

Это очень интересный эксперимент, но думаю ты облажаешься.

Почему ? Какие подводные камни ?

Ну я тебе уже писал — конкурентные запросы, ты кажется предложил делать блокировки, Ок, посмотрим или ты осилишь реализовать логику с блокировками, которая будет так же быстра как у современных баз, и при этом не будет связком спагетти кода.

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

Ну вот перестрой, посмотрим.

Дык, я про теорию в основном.
Начать чтото строить, это бросить одну задачу на пол пути и взятся за другую. Решил пока не метаться. Но надо будет к ней вернуться.

Ясно, я так и думал что неосилишь.

Там задача на самом деле состоит из двух частей. NoSql 30% и 70% rdbms. Вот мне даже не сильно лень наговнкодить на ноускл, как лень морочится с рдбмс. Если кто за меня рдбмс взял, и накодил модель складского учета, тогда интересно былобы сравнить.

О, вот терь кто-то еще твои невнятные идеи должен на 70% закодить. Ок.

Ну этож тебе нетерпится накодить ) Мне больше интересно аналитику провести, посчитать, ну иногда доску разрисовать. С кодингом там и так все понятно, ну по крайней мере для меня.

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

Моделирование бывает и в уме ) Например с компрессией сели посчитали и ничего не кодили.

А, ну моделируй TCP-H тест в уме, удачи тебе.

Да реляционка в раз 50 сольет ноускл, ток это никого не будет волновать потому что асид, миллион готовых специалистов и бла бла

Реляционки это неинтересно, там 90% оверхеда. Уже эта тема раскурена и прокурена, банальные проводки на ноускл считаются в 50ть раз быстрее чем на реляционке со всем букетом оптимизаций.

Мне было интересней переписать кей\валью хранилища типа std::map. Там нет оверхеда на асид, блокировки, многопользовательский режим. Вот где рубилово было.

wiki.pikosec.com/...maDB:Benchmarks

Но результат оказался немного предсказуем. Слились в несколько раз. Наверное писали эти структуры на местах по книжке Кнута с дедлайном — неделя. А не так как я, несколько лет, штук пятьдесят версий было, код вылизан до безобразия и в финальной версии штук 30 Goto красуется :)

Реляционки это неинтересно, там 90% оверхеда. Уже эта тема раскурена и прокурена, банальные проводки на ноускл считаются в 50ть раз быстрее чем на реляционке со всем букетом оптимизаций.
Можно посмотреть на детальные эксперименты по этому поводу?
Но результат оказался немного предсказуем. Слились в несколько раз. Наверное писали эти структуры на местах по книжке Кнута с дедлайном — неделя. А не так как я, несколько лет, штук пятьдесят версий было, код вылизан до безобразия и в финальной версии штук 30 Goto красуется :)
Я в ц++ не разбираюсь, но почто ты так по рагульски в мапу данные засовываешь? stdmap.insert ( std::make_pair(i, i) );

Это С++ детка © По-другому не позволяет.
Если Линукс ближе, есть бенчмарки с GLib.

Непонял, а stdmap[i] = i; почему нельзя вдруг стало?

Походу сложные блокировки это один из костылей которые накрутили на РДБМС
Сложные блокировки — это для нишебродов, которым не хватило денег на Оракл :)
А здесь я решил промасштабировать на бизнесс задачи.
Ну, на мой дилетантский взгляд, NoSQL хорош для больших объемов слабо связанных данных с преобладанием связей один ко многим, а с ростом сложности модели и появлением большого количества перекрестных ссылок начинает заруливать RDBMS и недостатки её не так критичны как любят об этом говорить носиквел-евангелисты. О каких «бизнесс задачах» ты говоришь?

Бизнесс задачи в которых нужно хранить историчность данных.
А таких задач в бизнессе уже походу 2\3. Ибо кто не хранит историчность, то можно
смело обвинять во всех смертных — логической неконсистентности данных, отсудствия приличных логов и тд. А если историчность хранить, то РДБМС превращается в неудачный низкоуровневый плуг.

В чём проблема с историчностью в РСУБД и как её обходят в нРСУБД?

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

С банками сталкивался, а вот с инвестиционными нет.
Там какаято особая специфика модели данных ?

Ну, мне кажется, там разница примерно как между этим и этим, в то время как и то и другое — калькулятор.

Подписаться на комментарии