Здравствуйте, Mamut, Вы писали:
M>что-то мне кажется, что такие решения не заходили дальше FOAF (friend of a friend), а для бОльшей вложенности все равно требовался геморрой.
Никакого геморроя, просто чуть более сложные запросы.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
N>Мы ушли куда-то в сторону. Начали с того, что adontz предложил мне какую-то странную ерунду в виде одной структуры таблицы без объяснения причин и подробностей. И никак не хочет рассказать, что дальше с этим делать.
Здравствуйте, netch80, Вы писали:
N>А откуда вывод про "неумение работать с RDBMS"? Незнание того конкретного средства, которое Вы почему-то считаете средством по дефолту, ещё ничего не означает
Назовите средство с которым знакомы, я весь внимание.
Здравствуйте, netch80, Вы писали:
N>Твой переводчик явно нуждается в починке.
Пока справляется, лапшу с ушей стряхивает исправно ))
N>Так всё-таки — будут конкретные предложения, или как обычно?
Предложения для чего? ты так и на объяснил в чем проблема положить реестр в реляционку, а по фотографии я не гадаю.
M>>тут не совсем правильный подход «вот вам проект, сделайте аналог». G>ИМХО самый правильный чтобы показать что NoSQLне хуже SQL_ных решений. G>Только вот не удается этого показать.
M>>Лучше посмотреть на то, какие проекты уже сделаны и экстраполировать. M>>на MongоDB валяется http://foursquare.com/ — по сути тот же stackoverflow — рейтинги, комментарии, badges и т.п. M>>на CouchDB вроде валяется http://www.mydochub.com/answers/ — практически аналог stackoverflow M>>ну и т.п. G>В основном это проекты, которые используют сильные стороны соответствующих технологий и не показываются слабых. G>Нужен именно real-world проект. Имхо stackoverflow — хороший вариант. Не слишком сложен чтобы охватить одному человеку, и не слишком банален как блог, магазин или "датчики".
А чем foursquare не real world? Аналог stackoverflow на mongodb есть
M>>что-то мне кажется, что такие решения не заходили дальше FOAF (friend of a friend), а для бОльшей вложенности все равно требовался геморрой. IB>Никакого геморроя, просто чуть более сложные запросы.
Ну как бы в том-то и дело
Если специальных иерархических данных нет (тот же MySQL), каждый следующий уровень дерева — это один-два лишних джойна.
Если специальные иерархические данные есть (последние версии MSSQL?), то тут я вообще не копенгаген
Справедливости ради, с деревьями (они же графы) весь NoSQL тоже не дружит, а граф-базы данных мне в NoSQL записывать не хочется
MV>What is key about the Stack Overflow story for me is the strong case they make for scale up as a viable solution for a certain potentially large class of problems. The publicity these days is all going scale out using NoSQL databases.
Там есть другой наброс
The refactorings will be to avoid excessive joins in a lot of key queries. This is the key lesson from giant multi-terabyte table schemas (like Google’s BigTable) which are completely join-free. This is significant because Stack Overflow's database is almost completely in RAM and the joins still exact too high a cost.
Что означает денормализацию и, по сути, key/value запросы То бишь NoSQL
C>>Ну да. Если понасиловать РБД, то часто можно научить её немного работать как NoSQL. IB>А если не насиловать, то она работает гораздо лучше, чем noSql.. ))
C>>Ок. "Способ представления кортежей с произвольным числом элементов" тебя устроит? IB>Абсолютно, тем более, что у реляционки с этим нет никаких проблем =))
MV>>What is key about the Stack Overflow story for me is the strong case they make for scale up as a viable solution for a certain potentially large class of problems. The publicity these days is all going scale out using NoSQL databases.
M>Там есть другой наброс
M>
M>The refactorings will be to avoid excessive joins in a lot of key queries. This is the key lesson from giant multi-terabyte table schemas (like Google’s BigTable) which are completely join-free. This is significant because Stack Overflow's database is almost completely in RAM and the joins still exact too high a cost.
M>Что означает денормализацию и, по сути, key/value запросы То бишь NoSQL
Не, так это уже был бы не наброс. Тут надо прочитать, осознать.... А там прямым текстом NoSQL (:
Здравствуйте, netch80, Вы писали:
G>>Маленький чеклист чтобы утверждать что таки знаешь SQL G>>(по MS SQL 2008, аналогичные возможности можно раскопать во всех современных СУБД)
N>Ну посмотрел. ~80% описанного хорошо знакомо. Даже больше, если послать нафиг XML. И что это даёт?
Ну так надо 100%, а то что написал adontz видимо не попало в 80%, вот непонятно было что за структура.
Здравствуйте, Mamut, Вы писали:
G>>Маленький чеклист чтобы утверждать что таки знаешь SQL G>>(по MS SQL 2008, аналогичные возможности можно раскопать во всех современных СУБД) G>>
G>>12)Нормализация (как минимум до 3 НФ)
G>>
M>При этом крупные проекты все, как в один голос, говорят, что не надо увлекаться нормализацией
Чтобы об этом говорить надо понимать что такое 3НФ и какие недостатки несет нормализация.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>и что за перебор и обработка?
M>Проще говоря, у нас две таблицы: items и item_tags. items примерно 3 000 000, item_tags более 100 000 000 (tag-ов 250 000).
То есть они таки считываются с диска.
M>Нужно найти количество и заданную страницу данных для items, в которых есть все перечисленные tag (может быть в запросе до 100 штук). При этом некоторые tags могут быть игнорируемые (их наличие необязательно). Некоторые tag-и такие, что встречаются в 60% всех items. Они могут в поиске сочетаться.
M>В общем, в упрощенном виде нечто такое:
M>
M>SELECT items.* FROM items
M> JOIN item_tags it1 ON items.item_id = it1.item_id
M> JOIN item_tags it2 ON items.item_id = it2.item_id
M> LEFT JOIN item_tags it3 ON items.item_id = it3.item_id /* игнорируемый */
M> ...
M>WHERE 1=1
M> AND it1.tag_id = @tag1
M> AND it2.tag_id = @tag2
M> AND it3.tag_id = @tag3
M> ....
M> AND/* Дополнительные условия */
M>ORDER BY/* агрегатные функции, иногда с кучей IF, подтаблицами, ... */
M>
M>И таких запросов надо выполнять несколько раз в секунду. Допустимо, чтобы изменения в таблицах не сразу отображались, а с задержкой.
SQL Server отлично такой запрос поборет при правильных индексах.
M>В общем тупой перебор по памяти (1G) дает 0.3 секунды, обработка еще 0.3
А считывание всего этого добра в память?
Здравствуйте, gandjustas, Вы писали:
M>>Проще говоря, у нас две таблицы: items и item_tags. items примерно 3 000 000, item_tags более 100 000 000 (tag-ов 250 000). G>То есть они таки считываются с диска.
M>>В общем тупой перебор по памяти (1G) дает 0.3 секунды, обработка еще 0.3 G>А считывание всего этого добра в память?
Считываются с диска раз в сутки при индексации. Потом формируется новый shared memory object, с которым идет дальнейшая работа. Старый уничтожается. Если бы этот гигабайт при каждом запросе считывался с диска, то наступили бы всеобщие грабли. Сейчас, за исключением 15 мин в день, дисковая активность в нулях.
M>>И таких запросов надо выполнять несколько раз в секунду. Допустимо, чтобы изменения в таблицах не сразу отображались, а с задержкой. G>SQL Server отлично такой запрос поборет при правильных индексах.
Но запрос немного упрощенный. Дополнительные условия состоят в том, что у item-ов есть типы. Два item-а одного типа, по возможности, не должны следовать друг за другом. Так что все равно выдачу надо было бы руками обрабатывать. При выдаче данные разбиваются на несколько потоков, которые надо смешать в определенной пропорции. Узнать, куда попадет тот или иной item можно только после выполнения агрегатной функции. Получаем несколько однотипных запросов с разными HAVING-ами.
В моих кривых руках базы работают прекрасно, если есть хотя бы один редкий tag, но вешаются при запросах, например, по двум тагам, когда первый используется в 60% всех item-ов, и второй примерно также. А если сюда добавить еще и третий такой же, то совсем плохо. В этом случае все равно в результате миллион записей, которые надо посчитать, отсортировать, ...
Опять же, написать такое на C++ для меня не проблема. В конце концов там вся на уровне лабораторной работы для нерадивых студентов первого курса. Все в моих руках. Плюс на сегодня большой запас по увеличению производительности в случае необходимости. Добавить те же индексы Но у меня нет никакой уверенности в том, что после долгого ковыряния в мануалах, настройке, подгонки, подкрутки, все это заработает с SQL-сервером. Допускаю, но хотелось бы увидеть. А также запаса на тот случай, что если все это дело в один прекрасный день завалится, то я смогу это быстро поправить. Также я не могу дать гарантию, что если требования изменятся, осилит ли их SQL-сервер. Например, добавится с десяток LEFT JOIN. Ну и прочие неприятности, типа изменился алгоритм, надо менять/перестраивать материализованные вьюхи. А что будет при этом при запросе к ним? И т. д. и т. п.
Гипотетически, в случае Oracle, например, меня смущает тот факт, что запросы строится динамически, не повторяются, а построение плана запроса достаточно дорогая операция.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
M>>>Проще говоря, у нас две таблицы: items и item_tags. items примерно 3 000 000, item_tags более 100 000 000 (tag-ов 250 000). G>>То есть они таки считываются с диска.
M>>>В общем тупой перебор по памяти (1G) дает 0.3 секунды, обработка еще 0.3 G>>А считывание всего этого добра в память?
M>Считываются с диска раз в сутки при индексации. Потом формируется новый shared memory object, с которым идет дальнейшая работа. Старый уничтожается. Если бы этот гигабайт при каждом запросе считывался с диска, то наступили бы всеобщие грабли. Сейчас, за исключением 15 мин в день, дисковая активность в нулях.
Те обновление раз в день происходит или как?
Кстати, что будешь делать если таблица вылезет за пределы доступной памяти на x86?
(подсказка: с базой ничего не надо придумывать)
M>>>И таких запросов надо выполнять несколько раз в секунду. Допустимо, чтобы изменения в таблицах не сразу отображались, а с задержкой. G>>SQL Server отлично такой запрос поборет при правильных индексах.
M>Но запрос немного упрощенный. Дополнительные условия состоят в том, что у item-ов есть типы. Два item-а одного типа, по возможности, не должны следовать друг за другом. Так что все равно выдачу надо было бы руками обрабатывать. При выдаче данные разбиваются на несколько потоков, которые надо смешать в определенной пропорции. Узнать, куда попадет тот или иной item можно только после выполнения агрегатной функции. Получаем несколько однотипных запросов с разными HAVING-ами.
Сами себе грабли придумываете.
M>В моих кривых руках базы работают прекрасно, если есть хотя бы один редкий tag, но вешаются при запросах, например, по двум тагам, когда первый используется в 60% всех item-ов, и второй примерно также. А если сюда добавить еще и третий такой же, то совсем плохо. В этом случае все равно в результате миллион записей, которые надо посчитать, отсортировать, ...
Базы данных вполне успешно обрабатывают такие ситуации. У них есть статистика использования индекса, они могут оценить селективность предикатов до их выполнения.
M>Опять же, написать такое на C++ для меня не проблема. В конце концов там вся на уровне лабораторной работы для нерадивых студентов первого курса. Все в моих руках. Плюс на сегодня большой запас по увеличению производительности в случае необходимости. Добавить те же индексы Но у меня нет никакой уверенности в том, что после долгого ковыряния в мануалах, настройке, подгонки, подкрутки, все это заработает с SQL-сервером. Допускаю, но хотелось бы увидеть. А также запаса на тот случай, что если все это дело в один прекрасный день завалится, то я смогу это быстро поправить. Также я не могу дать гарантию, что если требования изменятся, осилит ли их SQL-сервер. Например, добавится с десяток LEFT JOIN. Ну и прочие неприятности, типа изменился алгоритм, надо менять/перестраивать материализованные вьюхи. А что будет при этом при запросе к ним? И т. д. и т. п.
Ну ладно, честно признался что не очень в базе данных рубишь.
Здравствуйте, Mamut, Вы писали:
M>Если специальных иерархических данных нет (тот же MySQL), каждый следующий уровень дерева — это один-два лишних джойна.
Никаких лишних джойнов уровни не добавляют, просто структура данных чуть сложнее. И это именно "чуть", а не так фатально, как тут пытаются описать.
Здравствуйте, Mamut, Вы писали:
M>А можно пример?
пример чего? как это дело через еще одно отношение выразить? У меня и правда складывается впечатление, что адепты noSql на самом деле реляционки не знают. =)
Здравствуйте, gandjustas, Вы писали:
G>Те обновление раз в день происходит или как? G>Кстати, что будешь делать если таблица вылезет за пределы доступной памяти на x86? G>(подсказка: с базой ничего не надо придумывать)
Да, раз в день. Памяти 32G, используется 1G + 1G при индкскации. Как минимум запас в 10 раз есть. Это по самым скромным оценкам, 10 лет развития проекта. А это уже достаточно большой срок. За это время либо я умру, либо ишак.
G>Сами себе грабли придумываете.
G>Базы данных вполне успешно обрабатывают такие ситуации. У них есть статистика использования индекса, они могут оценить селективность предикатов до их выполнения.
Могут, а толку? Если в результате будет 1 000 000 item-ов, то хочешь-не хочешь придется их все обрабатывать. Как тут выручит селективность?
G>Ну ладно, честно признался что не очень в базе данных рубишь.
Зато разбираюсь в алгоритмах. И могу оценить верхнюю границу при условии, что база данных отработает запрос идеально (т. е. выполнит только те вычисления, что необходимы).
Здравствуйте, IB, Вы писали:
N>>Предложи метод укладки, а я оценю его адекватность для наших задач. IB>Ну, не читать же мне тут тебе ликбез по SQL-ю? =) Уложить в него можно все и это строго математически доказано. )
Уложить можно что угодно, куда угодно.
Вопрос в том, какие требования вытавляет кастомер к конечному продукту.
И здесь оказывается частенько, что NoSQL решения завязаны на специфику конкретного кастомера или отрасли.
Т.е. они тупо дешевле и оптимизированы исключительно под конкретные сценарии.
Здравствуйте, gandjustas, Вы писали:
N>>И где тут описанное тобой "основное хранилище"? G>Ты как-бы привел ваше РЕШЕНИЕ, а не задачу. Расскажи подробнее про задачу тебе решений накидают. G>Большинство обычных СУБД вытянут базы на 100гб и не поморщатся при нормальной схеме. Никаких распределенных хранилищ не понадобится.
Господи, что за мода приводить абсолютные цифры безо всякого базиса ?
На каком железе будут тянуться эти 100гб ?
За какое время вытянутся эти 100гб?
G>ЗЫ. Единственное во что реально упереться в СУБД, так это в скорость записи.
Опаньки ! А если кастомер требует скорость запись которая на порядок выше чем может выдержать твоя мега СУБД ?
Мы уже победили, просто это еще не так заметно...
Аналог stackoverflow на mongodb есть 
