Check Levi9 best QA positions to Backbase team! ✖
Вход и регистрация
×Закрыть
Разработка · 14 октября 2014, 18:00 2947
DNA Exp

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

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

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

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

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

Темы: NoSQL, RDBMS
👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

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

Beaver Green 15.10.2014 13:59

Спорить на тему 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
DNA Exp 17.10.2014 12:04

:-D


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

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

Ответить
Поддержать
DNA Exp
reality_hacker 17.10.2014 19:14

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

Ответить
Поддержать
DNA Exp
DNA Exp 17.10.2014 19:59

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

Ответить
Поддержать
reality_hacker
reality_hacker 17.10.2014 20:31

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

Ответить
Поддержать
DNA Exp
Tim Tretyak ASM, TS Consultant 18.10.2014 19:22

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

Ответить
Поддержать
DNA Exp
DNA Exp 18.10.2014 20:10

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

Ответить
Поддержать
Tim Tretyak
Tim Tretyak ASM, TS Consultant 19.10.2014 01:04

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

Ответить
Поддержать
DNA Exp
DNA Exp 19.10.2014 11:10

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

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

Ответить
Поддержать
Tim Tretyak
Tim Tretyak ASM, TS Consultant 19.10.2014 12:23
Это означает что в реляционке придётся на каждый чих гонять тяжелейшие запросы
Это вообще чистый легкий OLTP и с ним более чем сносно справляется любое кассовое ПО в режиме реального времени (между идентификацией скидочной карты и выбиванием чека). Тупой select sum по индексу из двух связанных по ID карточки таблиц. Где там тяжесть?
А аналитика на то и аналитика что нужна трём бухам в конце месяца
Та да — те же остатки на складах конечно трем бухам надо и не чаще раза в месяц. Заказ они, очевидно, по фазам луны делают. Особенно на продуктовый скоропортящийся товар или полуфабрикаты для кулинарии или ресторана, например.
Я практически досконально знаю механику работы розницы и ресторанов, т.к. внедрял такие системы. Не надо гадать — просто принимайте информацию.
Ответить
Поддержать
DNA Exp
DNA Exp 19.10.2014 13:01
Тупой select sum по индексу из двух связанных по ID карточки таблиц.

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

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

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

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

Ответить
Поддержать
Tim Tretyak
Tim Tretyak ASM, TS Consultant 19.10.2014 13:27
В таблице может быть сотни миллионов записей
С определенного количества записей реляционки начинают работать плохо, это факт. Партиционирование спасает в определенных случаях, но в данном значительно проще применить аргегацию — раз в сутки суммировать покупки за последние сутки и плюсовать к карточке.
Некоторый костыль, но работать будет.
.
Скидочная система вообще может не существовать — это необязательный атрибут для ритейла, а вот склады-заказы-производство есть у всех обязательно.
И, кстати, движняк по товарам не меньше, т.к. они участвуют во всех транзакциях на кассе в том числе и без скидок (и таких более 50%), а их движение тянет за собой целую бороду сопутствующих транзакций.
Ответить
Поддержать
DNA Exp
DNA Exp 20.10.2014 12:06
С определенного количества записей реляционки начинают работать плохо, это факт.
Факт.
Партиционирование спасает в определенных случаях, но в данном значительно проще применить аргегацию — раз в сутки суммировать покупки за последние сутки и плюсовать к карточке.
Некоторый костыль, но работать будет.

Костыль.

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

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

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

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

Ответить
Поддержать
Tim Tretyak
Владимир Чернышев Программист 19.10.2014 15:41

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

Ответить
Поддержать
DNA Exp
DNA Exp 19.10.2014 16:21

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

Ответить
Поддержать
Владимир Чернышев
Владимир Чернышев Программист 19.10.2014 20:50

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

Ответить
Поддержать
DNA Exp
DNA Exp 19.10.2014 21:23

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

Ответить
Поддержать
Владимир Чернышев
Serhii Zakrevskyi PM 16.10.2014 12:42

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

Ответить
Поддержать
Artyom Krivokrisenko 16.10.2014 10:46

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

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

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

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

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

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

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

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

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

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

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

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

Ответить
Поддержать
Artyom Krivokrisenko
DNA Exp 16.10.2014 11:56
как понял фаны «MongoDB, Cassandra, Reddis или Hbase.» — тоже не в состоянии показать примеры изящных решений, чтобы «запрос НЕ выполняется три часа»

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

Ответить
Поддержать
undefined pointer
undefined pointer 16.10.2014 12:10

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

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 12:12

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

Ответить
Поддержать
undefined pointer
undefined pointer 16.10.2014 12:20

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 12:35

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

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

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

Ответить
Поддержать
undefined pointer
undefined pointer 16.10.2014 12:45
Вот только хороший механик, если смотрит на новенькое выкрашеное авто с конвеера, видит недостатки
а пузатый болельщик видит плохую игру футболистов.

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

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

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

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 12:53
а пузатый болельщик видит плохую игру футболистов.
где прототипы, механик?

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

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

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

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

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

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

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

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

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

MongoDB, Cassandra, Reddis или Hbase
?
Не, не слышал. А зачем оно ?
Ответить
Поддержать
undefined pointer
undefined pointer 16.10.2014 13:19
И не просто отчет, а отчет с построением графика
QlikView не видели?

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 13:22

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

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

С

QlikView

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

Ответить
Поддержать
undefined pointer
undefined pointer 16.10.2014 13:27

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 13:32

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

Ответить
Поддержать
undefined pointer
undefined pointer 16.10.2014 13:50

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 14:36

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

Ответить
Поддержать
undefined pointer
DNA Exp 16.10.2014 13:13
пустомеля, вы сколько и каких проектов сделали на своем «процедурном подходе»? сколько заказчиков перевели, с «20 раз медленнее» на «один цикл и три простых формулы»?

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

Ответить
Поддержать
undefined pointer
undefined pointer 16.10.2014 13:24

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 13:26

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

Ответить
Поддержать
undefined pointer
Maks Rybalchenko 16.10.2014 16:02

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

Ответить
Поддержать
undefined pointer
DNA Exp 16.10.2014 16:32

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

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

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

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

Ответить
Поддержать
Maks Rybalchenko
Maks Rybalchenko 16.10.2014 16:44

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

Ответить
Поддержать
DNA Exp
undefined pointer 16.10.2014 16:38

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

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

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

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

Ответить
Поддержать
Maks Rybalchenko
Maks Rybalchenko 16.10.2014 16:52

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

Ответить
Поддержать
undefined pointer
undefined pointer 16.10.2014 17:15
разве у такого захочется учиться?
чел многократно отказался учиться у кого-либо и чего-либо.
у меня — совсем не обязательно.
более старший человек начинает «козырять» возрастом, опытом, кричать «сынок» и тд. и тп.
когда тебе начинают рассказывать о том как здорово было там где ты лично понабил немало шишек — ничего другого не остается :)
будьте более снисходительны :)
та да, надо было сразу пройти мимо. уже ж писал, решил не слушаться своей интуиции :)
и оказалось — напрасно. еще вот и вы мне выговаривать за это начали — что не прошел мимо :)
Ответить
Поддержать
Maks Rybalchenko
DNA Exp 16.10.2014 17:28
чел многократно отказался учиться у кого-либо и чего-либо.
у меня — совсем не обязательно.

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

Ответить
Поддержать
undefined pointer
DNA Exp 16.10.2014 17:05

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

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

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 17:26
пусть спец по форсункам не берется учить водить машину.

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

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

Ответить
Поддержать
undefined pointer
undefined pointer 16.10.2014 17:30

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 17:38

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


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

Ответить
Поддержать
undefined pointer
DNA Exp 16.10.2014 17:45

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

Ответить
Поддержать
undefined pointer
undefined pointer 16.10.2014 18:01

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

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

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

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 18:32
вы кодеры «почему-то» уверены что с вами обязаны соревноваться.
впредь — всегда засчитывай. никто с кодером в скорости кодирования тягаться не будет. ну, кроме другого кодера.

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

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

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

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

Ответить
Поддержать
undefined pointer
Oleksandr Fedirko BI developer в Itera 17.10.2014 11:16
select ... from .. where ...group by ...
воу, воу, воу
Вам понятие «Хранилище данных» (Datawarehouse) о чём-то говорит?
Подходы Кимбала и Инмона изучали?
Многомерные (MOLAP) движки смотрели?
Который делает апроксимацию и строит график по табличке в 56 гигабайт.
В базе находятся несколько миллиардов фактов о документах и словах
1. И все 56 гигабайт постоянно изменяются?
2. Или они статические, а данные только приходят новые?
Если ответы 1. нет, 2. да, то Ваша задача решаема реляционным подходом.
Ответить
Поддержать
DNA Exp
DNA Exp 17.10.2014 11:21
1. И все 56 гигабайт постоянно изменяются?
2. Или они статические, а данные только приходят новые?
Если ответы 1. нет, 2. да, то Ваша задача решаема реляционным подходом.

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

Ответить
Поддержать
Oleksandr Fedirko
reality_hacker 17.10.2014 19:18

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

Ответить
Поддержать
DNA Exp
DNA Exp 18.10.2014 20:29

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

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

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

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

Ответить
Поддержать
Oleksandr Fedirko
DNA Exp 17.10.2014 11:44

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


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

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

Ответить
Поддержать
Oleksandr Fedirko
Andrew Sevastianov 15.10.2014 15:39

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

Ответить
Поддержать
Дмитрий Демьяненко BA/UX 15.10.2014 15:35

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

Ответить
Поддержать
Pavlo Suikov меня интересуют только мыши, их стоимость, и где приобрести в GlobalLogic 15.10.2014 15:24

NoSQL is co-SQL.

Ответить
Поддержать
Beaver Green 15.10.2014 13:59

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

Ответить
Поддержать
undefined pointer 15.10.2014 14:14

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

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

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

Ответить
Поддержать
Beaver Green
reality_hacker 15.10.2014 18:20
а с инженерной точки зрения «NoSQL vs RDBMS» это выбор в пространстве CAP теоремы.
Читаю этот топик, и одни фейспалмы возникают.
Ответить
Поддержать
undefined pointer
Iryna Volkodav engineer 15.10.2014 18:59

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

Ответить
Поддержать
reality_hacker
reality_hacker 15.10.2014 19:06

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

Ответить
Поддержать
Iryna Volkodav
Iryna Volkodav engineer 15.10.2014 19:11

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

Ответить
Поддержать
reality_hacker
undefined pointer 15.10.2014 19:15
Я думала, что SQL — это AC
он подмену сделал :)

RDBMS это обычно AC

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

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

Ответить
Поддержать
Iryna Volkodav
Iryna Volkodav engineer 15.10.2014 19:21

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

Ответить
Поддержать
undefined pointer
reality_hacker 15.10.2014 19:47
А есть ли SQL хранилища с CP?
Элементарный мастер слейв с синхронной репликацией — это AP
Ответить
Поддержать
Iryna Volkodav
reality_hacker 15.10.2014 20:08

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

Ответить
Поддержать
Iryna Volkodav
Iryna Volkodav engineer 15.10.2014 20:43

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

Ответить
Поддержать
reality_hacker
undefined pointer 15.10.2014 19:12

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

а с инженерной точки зрения
то бишь — с практической, а не академической.
с выбора того что есть в предложении, а не с того что могло бы быть.
и я написал
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

Ответить
Поддержать
reality_hacker
reality_hacker 15.10.2014 19:49
о бишь — с практической, а не академической.
Ну вот именно с практической, как настроишь — так и будет?
SQL это язык :) подобие которого прикручивают и к NoSQL базам.
из доки:
Retrieve data from a Cassandra table.
То что ты написал называется CQL. A SQL по определению требует РДБМС. Учи матчасть.
Ответить
Поддержать
undefined pointer
Борис Бажура Технічний директор 16.10.2014 15:02
A SQL по определению требует РДБМС.

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

Ответить
Поддержать
reality_hacker
reality_hacker 16.10.2014 19:16

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

Ответить
Поддержать
Борис Бажура
undefined pointer 16.10.2014 16:35
То что ты написал называется CQL
я в курсе как называется.
там откуда копипастил даже в линке написано.
www.datastax.com/...e/select_r.html

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

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

Ответить
Поддержать
reality_hacker
reality_hacker 16.10.2014 19:18

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

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

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

Ответить
Поддержать
reality_hacker
undefined pointer 16.10.2014 21:26

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

Ответить
Поддержать
reality_hacker
reality_hacker 16.10.2014 21:27

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

Ответить
Поддержать
undefined pointer
undefined pointer 16.10.2014 23:14

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

Ответить
Поддержать
reality_hacker
Grez 16.10.2014 22:55

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

Ответить
Поддержать
undefined pointer
undefined pointer 16.10.2014 23:11

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

Ответить
Поддержать
Grez
Grez 16.10.2014 23:22

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

Ответить
Поддержать
undefined pointer
undefined pointer 17.10.2014 08:01

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

Ответить
Поддержать
Grez
DNA Exp 15.10.2014 14:37

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

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

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

Ответить
Поддержать
Beaver Green
undefined pointer 15.10.2014 14:51
Вот она папка о «Иване Иванове», здесь есть всё.
а обычно требуется
выдайте мне фамилии тех у кого в этом году юбилей.
а не «всё об Иванове»

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

Вот она папка о «Иване Иванове»
Документо-ориентированные БД так и устроены.
Или реализации, расширения RDBMS
Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 14:57

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

Ответить
Поддержать
undefined pointer
undefined pointer 15.10.2014 15:10
Удобней и наглядней работать с досье.
нет.

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

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

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

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

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

Например:

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

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

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

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

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

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

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 15:21
1 дата1 Иванов хочет взять кредит на машину
2 дата2 Петрова выделила Иванову деньги на кредит
3 дата3 Иванов взял кредит на машину

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответить
Поддержать
undefined pointer
undefined pointer 15.10.2014 16:47

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

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 17:01

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 17:34
минусы — ручное написание выборок данных.
если какая-то выборка не предусмотрена, то можно нарваться на аналог «фулскана»

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

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

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

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

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

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

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 17:55
лечится — настройкой индексов.

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

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

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

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

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

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

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

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

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

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 18:09
у-у-у, как все запущено :)
про Full-text индексы — не слышали?

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

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

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

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

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

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

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

Ответить
Поддержать
DNA Exp
Iryna Volkodav engineer 15.10.2014 18:07
вы попробуйте на документо-ориентированный БД только целостность бизнес транзакций на изменение обеспечить, при конкурентном доступе ;)
На сколько я понимаю, то есть для этого решения, определенные классом NewSQL решений, которые пропагандирует, как более перспективную альтернативу NoSQL решениям — Michael Stonebraker (один из основных разработчиков Ingres и PostgreSQL).

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

Ответить
Поддержать
undefined pointer
DNA Exp 15.10.2014 18:15

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

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

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

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

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

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

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

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

Ответить
Поддержать
undefined pointer
undefined pointer 15.10.2014 22:46

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 23:00

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

Ответить
Поддержать
reality_hacker
undefined pointer 15.10.2014 23:06

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 23:09

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

Ответить
Поддержать
undefined pointer
Yuriy Shulima programmer 15.10.2014 23:15

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

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

Ответить
Поддержать
DNA Exp
reality_hacker 15.10.2014 23:21
Всетаки вставка\чтение 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
Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 23:26

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

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 23:33

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

Ответить
Поддержать
reality_hacker
reality_hacker 15.10.2014 23:39 
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сек.
Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 23:48

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

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

Ответить
Поддержать
reality_hacker
reality_hacker 15.10.2014 23:50

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 23:55

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

Ответить
Поддержать
reality_hacker
reality_hacker 16.10.2014 00:00

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 00:05
cpubenchmark.net/...1214&cpuCount=2

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

Ответить
Поддержать
reality_hacker
reality_hacker 16.10.2014 00:14

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 00:01

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

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

Ответить
Поддержать
reality_hacker
Yuriy Shulima programmer 15.10.2014 23:51

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

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

Ответить
Поддержать
DNA Exp
reality_hacker 15.10.2014 23:54

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

Ответить
Поддержать
Yuriy Shulima
Yuriy Shulima programmer 16.10.2014 00:10

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

Ответить
Поддержать
reality_hacker
DNA Exp 16.10.2014 00:15

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

Ответить
Поддержать
reality_hacker
reality_hacker 16.10.2014 00:16

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 00:17

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

Ответить
Поддержать
reality_hacker
reality_hacker 16.10.2014 00:18

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

Ответить
Поддержать
DNA Exp
reality_hacker 16.10.2014 00:23

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 00:25

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

Ответить
Поддержать
reality_hacker
reality_hacker 16.10.2014 00:27

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 00:30

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

Ответить
Поддержать
reality_hacker
reality_hacker 16.10.2014 00:32

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 00:33

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

Ответить
Поддержать
reality_hacker
reality_hacker 16.10.2014 00:42

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 00:46

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

Ответить
Поддержать
reality_hacker
reality_hacker 16.10.2014 00:47

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 00:55

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

Ответить
Поддержать
reality_hacker
reality_hacker 16.10.2014 00:56

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

Ответить
Поддержать
DNA Exp
Gabriel Angelos 16.10.2014 00:57

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

Ответить
Поддержать
reality_hacker
reality_hacker 16.10.2014 00:57

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

Ответить
Поддержать
Gabriel Angelos
DNA Exp 16.10.2014 01:14

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

Ответить
Поддержать
reality_hacker
reality_hacker 16.10.2014 01:24

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 01:35

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

Вот
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);

}

}

Ответить
Поддержать
reality_hacker
DNA Exp 16.10.2014 01:39

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

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

Ответить
Поддержать
reality_hacker
reality_hacker 16.10.2014 01:45

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 01:49

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

Ответить
Поддержать
reality_hacker
reality_hacker 16.10.2014 01:55

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

Ответить
Поддержать
DNA Exp
reality_hacker 16.10.2014 01:46
На Си я переделал и теперь так заполняю рандом.
intKeys[i] = rand()
Полностью по аналогии с джабой.
НУ может у жабы рандом покруче..
Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 01:51

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

Ответить
Поддержать
reality_hacker
DNA Exp 16.10.2014 01:47

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

Ответить
Поддержать
DNA Exp
reality_hacker 16.10.2014 03:18
На Си я переделал и теперь так заполняю рандом.
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;
}
Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 09:41
#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 одна из самых тормознутых шарманок.

Ответить
Поддержать
reality_hacker
DNA Exp 16.10.2014 10:06

Вот, я феншуйно переписал.
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;
}

Ответить
Поддержать
reality_hacker
Gabriel Angelos 16.10.2014 00:56

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

Ответить
Поддержать
DNA Exp
Yuriy Shulima programmer 16.10.2014 09:44

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

Ответить
Поддержать
DNA Exp
Artyom Krivokrisenko 16.10.2014 10:00

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

Ответить
Поддержать
Yuriy Shulima
DNA Exp 16.10.2014 10:02

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

Ответить
Поддержать
Yuriy Shulima
Yuriy Shulima programmer 16.10.2014 10:42

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

Ответить
Поддержать
DNA Exp
Artyom Krivokrisenko 16.10.2014 10:45

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

Ответить
Поддержать
Yuriy Shulima
Yuriy Shulima programmer 16.10.2014 10:52
в цикле будет давать числа, у которых у всех (hash % hashtableSize) всегда одинаковый, снизит эфективность работы хеш таблицы

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

Ответить
Поддержать
Artyom Krivokrisenko
DNA Exp 16.10.2014 10:51
Т.е. любые комбинации, равномерное распределение — и есть вариант, когда коллизий наименьше.

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

Ответить
Поддержать
Yuriy Shulima
Yuriy Shulima programmer 16.10.2014 11:22

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 11:59

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

Ответить
Поддержать
Yuriy Shulima
DNA Exp 16.10.2014 00:03

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

Ответить
Поддержать
Yuriy Shulima
Yuriy Shulima programmer 16.10.2014 00:05

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

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

Ответить
Поддержать
DNA Exp
Artyom Krivokrisenko 16.10.2014 09:32
Вот тут есть бенчмарк.
www.sql.ru/...s/stebelek/1269
И в чем там состоит слив дотнета?
Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 23:36

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

Ответить
Поддержать
reality_hacker
DNA Exp 15.10.2014 22:55

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

Ответить
Поддержать
undefined pointer
undefined pointer 15.10.2014 23:19

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

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

Ответить
Поддержать
DNA Exp
Владимир Чернышев Программист 17.10.2014 18:57

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 18.10.2014 23:47

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

Ответить
Поддержать
Владимир Чернышев
Владимир Чернышев Программист 19.10.2014 15:57

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

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

Ответить
Поддержать
DNA Exp
undefined pointer 15.10.2014 18:18

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

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

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

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

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

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

Ответить
Поддержать
Iryna Volkodav
DNA Exp 15.10.2014 19:47
о есть — если нет памяти размером с данные (пользовательские плюс служебные) то в сторону NewSQL можно и не смотреть :)

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

Ответить
Поддержать
undefined pointer
undefined pointer 15.10.2014 22:51

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 23:59

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

Ответить
Поддержать
undefined pointer
undefined pointer 16.10.2014 08:15

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 09:18

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

Ответить
Поддержать
undefined pointer
undefined pointer 16.10.2014 09:34

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 16.10.2014 09:51

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

Ответить
Поддержать
undefined pointer
undefined pointer 16.10.2014 10:51

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

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

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

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

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


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

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

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

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

Ответить
Поддержать
undefined pointer
undefined pointer 16.10.2014 12:32

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

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

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

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

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

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

Ответить
Поддержать
Beaver Green
Beaver Green 15.10.2014 15:48
А РДБМС это достаточно неудачно.
Это потому — что такие жесткие требования к этой системе поставили. Что бы данные хранились в одном месте, были всегда непротиворечивыми, всегда актуальными и т.д. И при этом что бы разные пользователи одновременно меняли разные куски данных, но не возникало конфликтов.
И это работает именно так, как задумано. Так почему Вы говорите «неудачно»? Наверно потому, что у Вас были совсем другие требования в приоритете. Тогда нужен и подход другой. Например, собрать информацию из 20 таблиц и продублировать в NOSQL.
Ответить
Поддержать
DNA Exp
undefined pointer 15.10.2014 15:51
Всё лежит в разных углах
а никуда не денетесь от углов.
либо раскладывайте сразу по разным углам
либо потом по всем ищите то что было бы разложено в первом случае

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 16:02

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

Ответить
Поддержать
undefined pointer
Дмитрий Демьяненко BA/UX 15.10.2014 15:43
невозможно создать универсальную систему хранения, которая бы удовлетворяла всем критериям.
невозможно имеет смысл заменить на — дорого. И тут стоит учитывать, то сто 20 лет назад было «дорого», сегодня уже вполне может составлять — «копейки».
Ответить
Поддержать
Beaver Green
Beaver Green 15.10.2014 15:54

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

Ответить
Поддержать
Дмитрий Демьяненко
Дмитрий Демьяненко BA/UX 15.10.2014 16:02

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

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

Ответить
Поддержать
Beaver Green
Beaver Green 15.10.2014 16:07

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

Ответить
Поддержать
Дмитрий Демьяненко
Борис Бажура Технічний директор 15.10.2014 12:47

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

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

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

Ответить
Поддержать
DNA Exp 15.10.2014 12:58

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

Ответить
Поддержать
Борис Бажура
Dmitriy Onykyyenko dev 15.10.2014 08:57
Что касается принципа RDBMS «изменения нужно вносить только в одно место», то зачастую, как не странно, оно противоречит современным требованиям бизнесса.

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

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

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

Ответить
Поддержать
Олексій Пєніє Developer, Java 15.10.2014 09:38

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

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

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

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

Ответить
Поддержать
Dmitriy Onykyyenko
Dmytro Yeremieiev Web developer – Ciklum 15.10.2014 10:02
Или таки продумаете ДУБЛИРОВАНИЕ товара, фиксируя все данные на момент начала транзакции?
MS SQL Server за вас это делает в режимах SNAPSHOT и READ COMMITED SNAPSHOT.
Ответить
Поддержать
Олексій Пєніє
DNA Exp 15.10.2014 10:17
MS SQL Server

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

Ответить
Поддержать
Dmytro Yeremieiev
Dmytro Yeremieiev Web developer – Ciklum 15.10.2014 10:29
Это блокировочник (а не версионник). Обычно он просто блокирует запись. Тоесть физически дубля нет.
Вы хотя бы обратились к гуглу для начала если не работали с MS SQL. Вот мой пруф msdn.microsoft.com/...y/tcbchxcb(v=vs.110).aspx
Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 10:46

Спасибо за ссылку. Я начинал работать с 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

Ответить
Поддержать
Dmytro Yeremieiev
undefined pointer 15.10.2014 11:38
это СВОИ ИНДЕКСЫ, которые как-то хитрожопо спрятались от теории
именно.

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

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

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

Ответить
Поддержать
Beaver Green
DNA Exp 15.10.2014 10:15
Если она будет в адекватной НФ данные будут обновляться в одном месте.

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

Ответить
Поддержать
Dmitriy Onykyyenko
Dmitriy Onykyyenko dev 15.10.2014 10:24

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 10:50

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

Ответить
Поддержать
Dmitriy Onykyyenko
Dmitriy Onykyyenko dev 15.10.2014 11:13

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 11:28
Нормальная схема в вашем случае дающая возможность обеспечить ссылочную целостность делается вынесением адресов в отдельную таблицу в первую очередь.

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

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

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

Ответить
Поддержать
Dmitriy Onykyyenko
Dmitriy Onykyyenko dev 15.10.2014 11:41
Эта заплатка из разряда "Ну всё, я починил!"©
это еще иногда называется нормализация БД и создание схемы данных.
А эта вещь уже интересней, но как не странно она тоже является определенным костылем.
Это задача, которая решается добавлением атрибутов к сущности. Тоже на этапе проектирования бд и создания схемы данных.
Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 11:49

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

Ответить
Поддержать
Dmitriy Onykyyenko
Yuriy Shulima programmer 15.10.2014 21:27

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

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 21:40
Покажите как сделать нормальную схему данных, без оверхеда.

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

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

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

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

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

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

goto step1

Ответить
Поддержать
Yuriy Shulima
Yuriy Shulima programmer 15.10.2014 22:10

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

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

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

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

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

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

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

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

Premature optimization is the root of all evil.

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 22:19
Не думайте об оверхеде, пусть субд о нем думает.

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

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

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

Ответить
Поддержать
Yuriy Shulima
Yuriy Shulima programmer 15.10.2014 22:24
А в вас вот нет понимания разделения слоев. Здесь прилепим на скотч, вот здесь у нас две колоночки, вот там щас еще одну базистенку специально под историчность. В итоге спать прийдется на досках, сбитых из костылей и перемотаных скотчем.

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 22:35
Неудосбства только в написании запросов.

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

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

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

Ответить
Поддержать
Yuriy Shulima
Yuriy Shulima programmer 15.10.2014 22:53

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

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

Ответить
Поддержать
DNA Exp
Tim Tretyak ASM, TS Consultant 15.10.2014 10:36

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 10:50

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

Ответить
Поддержать
Tim Tretyak
Tim Tretyak ASM, TS Consultant 15.10.2014 11:16

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 11:35

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

Ответить
Поддержать
Tim Tretyak
Tim Tretyak ASM, TS Consultant 15.10.2014 11:44

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 12:03
А на уровне сиквела никаких уровней нет — он сильно старше этих концепций.

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

Ответить
Поддержать
Tim Tretyak
Tim Tretyak ASM, TS Consultant 15.10.2014 14:40

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

Ответить
Поддержать
DNA Exp
undefined pointer 15.10.2014 11:50
Получается мы не сможем из базы получить информацию, по какому действительно адресу произошла сделка.
хотя уже упомянули, но мне тоже бросилась в глаза эта ошибка — проектирования.

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

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

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

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

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

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

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 12:01
Так вот в приведенной схеме таблиц получение данных «покупатель совершал покупки по таким то адресам» — не предусмотрено. оно — случайно так вышло.

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

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

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

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

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

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

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 12:39

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

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

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

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

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

Ответить
Поддержать
DNA Exp
Maryna Shabalina водитель 26.03.2015 13:06
Поэтому и приходится проектировать работу с хронологией изменений поля — отдельно. специально предусматривать

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

Ответить
Поддержать
undefined pointer
Bender Tordeur Rodriguez 14.10.2014 21:23
Эх, неужели нет желающих пораскачивать «священную корову» ?
Люди решают хорошая Катя или плохая, а ты тут с какими-то DBMS.
Ответить
Поддержать
DNA Exp 14.10.2014 21:29

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

Ответить
Поддержать
Bender Tordeur Rodriguez
Антон Харуйманов 15.10.2014 00:20

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

Ответить
Поддержать
Bender Tordeur Rodriguez
reality_hacker 15.10.2014 01:00
Она ещё дралась с учителем по физкультуре.
Прозвище просто обязывало побеждать.
Ответить
Поддержать
Антон Харуйманов
DNA Exp 14.10.2014 21:07

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

Ответить
Поддержать
reality_hacker 14.10.2014 21:13

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

Ответить
Поддержать
DNA Exp
DNA Exp 14.10.2014 21:26

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

Ответить
Поддержать
reality_hacker
Bender Tordeur Rodriguez 14.10.2014 21:29
приимущества noSQL перед РДБМС
РДБМС — сакс, монга рулит, пыщ-пыщ :)
Ответить
Поддержать
DNA Exp
DNA Exp 14.10.2014 21:35

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

Ответить
Поддержать
Bender Tordeur Rodriguez
DNA Exp 14.10.2014 21:55

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

Ответить
Поддержать
Bender Tordeur Rodriguez
Grez 15.10.2014 09:13

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

Ответить
Поддержать
Bender Tordeur Rodriguez
reality_hacker 14.10.2014 21:29

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

Ответить
Поддержать
DNA Exp
DNA Exp 14.10.2014 21:44

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

Ответить
Поддержать
reality_hacker
reality_hacker 14.10.2014 21:50

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

Ответить
Поддержать
DNA Exp
DNA Exp 14.10.2014 22:04

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

Ответить
Поддержать
reality_hacker
reality_hacker 14.10.2014 22:08

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

Ответить
Поддержать
DNA Exp
DNA Exp 14.10.2014 22:12

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

Ответить
Поддержать
reality_hacker
reality_hacker 14.10.2014 22:14

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

Ответить
Поддержать
DNA Exp
DNA Exp 14.10.2014 22:23

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

Ответить
Поддержать
reality_hacker
reality_hacker 14.10.2014 22:27

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

Ответить
Поддержать
DNA Exp
DNA Exp 14.10.2014 22:43

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

Ответить
Поддержать
reality_hacker
reality_hacker 14.10.2014 23:34

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 00:01

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

Ответить
Поддержать
reality_hacker
reality_hacker 15.10.2014 00:02

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 00:07

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

Ответить
Поддержать
reality_hacker
reality_hacker 15.10.2014 00:09

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

Ответить
Поддержать
DNA Exp
DNA Exp 15.10.2014 00:14

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

Ответить
Поддержать
reality_hacker
DNA Exp 15.10.2014 00:27

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

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

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

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

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

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

Ответить
Поддержать
reality_hacker
reality_hacker 15.10.2014 18:19

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

Ответить
Поддержать
DNA Exp
bayda 15.10.2014 05:59
Походу сложные блокировки это один из костылей которые накрутили на РДБМС
Сложные блокировки — это для нишебродов, которым не хватило денег на Оракл :)
Ответить
Поддержать
DNA Exp
Bender Tordeur Rodriguez 14.10.2014 21:54
А здесь я решил промасштабировать на бизнесс задачи.
Ну, на мой дилетантский взгляд, NoSQL хорош для больших объемов слабо связанных данных с преобладанием связей один ко многим, а с ростом сложности модели и появлением большого количества перекрестных ссылок начинает заруливать RDBMS и недостатки её не так критичны как любят об этом говорить носиквел-евангелисты. О каких «бизнесс задачах» ты говоришь?
Ответить
Поддержать
DNA Exp
DNA Exp 14.10.2014 22:03

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

Ответить
Поддержать
Bender Tordeur Rodriguez
Владимир Чернышев Программист 17.10.2014 16:20

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

Ответить
Поддержать
DNA Exp
DNA Exp 14.10.2014 22:24

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

Ответить
Поддержать
Bender Tordeur Rodriguez
DNA Exp 15.10.2014 00:29

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

Ответить
Поддержать
Bender Tordeur Rodriguez
Bender Tordeur Rodriguez 15.10.2014 00:50

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

Ответить
Поддержать
DNA Exp

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

Не подписываться

Воспользуйтесь аккаунтом

×
с условиями использования сайта и политикой конфиденциальности.