Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Аноним, Вы писали: А>>Даст свободное время на реализацию бизнес логики, т.к. вы престанете заниматься фигней, закручивая гайки растущему организму. А>>В начале нужно делом заниматься. При этом еще не известно какие данные и структуры там будут. Это известно лишь когда проект закончен. Вот когда проект принесет вам миллиард долларов, купите себе остров, вот там тогда до старости можете переписывать на RDBMS, придумывать нормальные формы, индексы, вьюхи и тригеры. S>А по-моему всё строго наоборот. Там, где на RDBMS я могу накидать структуру нормализованной базы и взлететь,
А откуда вы в начале проекта узнаете какая структура должна быть в конце проекта? Попросите написать 600 страничное ТЗ со всеми ER и ззкесами, и цифрами описываюимим предположительное количество операций каждого вида? Если вам такое предоставят — нужно писать под RDBMS, вы совершенно правы.
S>подкручивая индексы и денормализуя на лету по мере роста нагрузки, на NoSQL я буду вынужден заранее проектировать всю структуру с учётом будущей (пока ещё неизвестной) нагрузки.
Посмотрите внимательней на NoSQL бд. Вот возмем самую популярную: MongoDB. Скажите, что именно вы будете делать в контектсе "проектирования"? Именно при прочих равных.
Рекомендую всеже внимательней посмотреть, почитать хоть немного, с такимим представлениями странный разговор получается.
И обратите внимание что NoSQL популярен именно в стартапах. Может потому что программисту удобней описывать классы в коде, просто как как объект его области, как удобней использовать в коде. А с хранением, запросами и прочим ему сейчас некогда заморачиваться. Лишь положил — прочитал, а в какой структуре это будет хранить БД его не касается. А завтра он поймет что вообще не так писал. Или новый тренд в интернете. Или еще чтото. Он не знает что завтра. Но когда наступит завтра — он легко поправит свой код, а БД под него сама подстроится.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, Аноним, Вы писали: А>>>Даст свободное время на реализацию бизнес логики, т.к. вы престанете заниматься фигней, закручивая гайки растущему организму. А>>>В начале нужно делом заниматься. При этом еще не известно какие данные и структуры там будут. Это известно лишь когда проект закончен. Вот когда проект принесет вам миллиард долларов, купите себе остров, вот там тогда до старости можете переписывать на RDBMS, придумывать нормальные формы, индексы, вьюхи и тригеры. S>>А по-моему всё строго наоборот. Там, где на RDBMS я могу накидать структуру нормализованной базы и взлететь,
А>А откуда вы в начале проекта узнаете какая структура должна быть в конце проекта? Попросите написать 600 страничное ТЗ со всеми ER и ззкесами, и цифрами описываюимим предположительное количество операций каждого вида? Если вам такое предоставят — нужно писать под RDBMS, вы совершенно правы.
А если не предоставят, то тем более нужно под RDBMS писать. Иначе понадобится делать заппросы, на которые изначально не рассчитывал и придется плодить индексы под каждый запрос.
А>И обратите внимание что NoSQL популярен именно в стартапах.
Потому что там традиционно не хватает нормальных программистов СУБД.
Ниче что треть программистов, работающих с БД, не понимают что такое индекс? Может это проблема СУБД?
А>Может потому что программисту удобней описывать классы в коде, просто как как объект его области, как удобней использовать в коде. А с хранением, запросами и прочим ему сейчас некогда заморачиваться. Лишь положил — прочитал, а в какой структуре это будет хранить БД его не касается.
Так и с реляционными БД можно.
А>А завтра он поймет что вообще не так писал. Или новый тренд в интернете. Или еще чтото. Он не знает что завтра. Но когда наступит завтра — он легко поправит свой код, а БД под него сама подстроится.
Прям сама? Вот хранили авторов статей вместе со статьями, а потом решили отдельно, подстроится?
А как она будет пдстраиваться после развертывания у клиента?
ЗЫ. Уже заметил проблему с тем что не могут люди сказать зачем им нужна NoSQL база кроме "for scaling". Горизонтальная масштабируемость съела моск.
Интересно будет посмотреть куда оно все пойдет когда SSD массово войдут на рынок.
Здравствуйте, gandjustas, Вы писали:
G>ЗЫ. Уже заметил проблему с тем что не могут люди сказать зачем им нужна NoSQL база кроме "for scaling". Горизонтальная масштабируемость съела моск.
Вот здесь можно посмотреть аргументированное изложение позиции сторонников noSQL на примере MongoDB: MongoDB is Web Scale
Re[5]: NoSQL vs RDBMS
От:
Аноним
Дата:
07.10.10 20:52
Оценка:
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, Sinclair, Вы писали:
S>>>Здравствуйте, Аноним, Вы писали: А>>>>Даст свободное время на реализацию бизнес логики, т.к. вы престанете заниматься фигней, закручивая гайки растущему организму. А>>>>В начале нужно делом заниматься. При этом еще не известно какие данные и структуры там будут. Это известно лишь когда проект закончен. Вот когда проект принесет вам миллиард долларов, купите себе остров, вот там тогда до старости можете переписывать на RDBMS, придумывать нормальные формы, индексы, вьюхи и тригеры. S>>>А по-моему всё строго наоборот. Там, где на RDBMS я могу накидать структуру нормализованной базы и взлететь,
А>>А откуда вы в начале проекта узнаете какая структура должна быть в конце проекта? Попросите написать 600 страничное ТЗ со всеми ER и ззкесами, и цифрами описываюимим предположительное количество операций каждого вида? Если вам такое предоставят — нужно писать под RDBMS, вы совершенно правы.
G>А если не предоставят, то тем более нужно под RDBMS писать. Иначе понадобится делать заппросы, на которые изначально не рассчитывал и придется плодить индексы под каждый запрос.
Индексы не зависят от типа БД. Нужны значит нужны. Много значит много. Может быть и мало. Поинт в том что ее можно гибко менять, тебя никто не ограничивает ни типами данных, ни струтурой таблицы. Чаще всего по началу очень сложно придумать нормальную структуру со всем связми, гораздо проще хранить в разных ячейках разное количество столбцов, по ситуации.
А>>И обратите внимание что NoSQL популярен именно в стартапах. G>Потому что там традиционно не хватает нормальных программистов СУБД. G>Ниче что треть программистов, работающих с БД, не понимают что такое индекс? Может это проблема СУБД?
Это проблема. Проблема того что в стартапе не так много денег. И нанять админа БД, который по факту будет работать несколько часов в месяц, но при этом постоянно ворчать "да что вы все не можете определится с тем какая у вас структура" слишком дорогое удовольствие. Это проблема.
Так что вот такая экономия. Ну классически: нет денег -> нет человека -> нет проблемы.
А>>Может потому что программисту удобней описывать классы в коде, просто как как объект его области, как удобней использовать в коде. А с хранением, запросами и прочим ему сейчас некогда заморачиваться. Лишь положил — прочитал, а в какой структуре это будет хранить БД его не касается. G>Так и с реляционными БД можно.
а вырост, А>>А завтра он поймет что вообще не так писал. Или новый тренд в интернете. Или еще чтото. Он не знает что завтра. Но когда наступит завтра — он легко поправит свой код, а БД под него сама подстроится. G>Прям сама? Вот хранили авторов статей вместе со статьями, а потом решили отдельно, подстроится?
Сама в том смысле что не нужно делать новые запросы, новые меппинги и пр. Ведь никто не мешает хранить в одной таблице разные классы, или разные версии одного класса, или иерархию классов (не в смысле дерева, а в смысле хранить в одной таблице объекты класса Rectangle, Box, Ellipse, которые из учебников про ООП), или класс котором значения полей могут разных типов, при этом не начиная каждый раз придумывать новую систему реляционных связей.
G>А как она будет пдстраиваться после развертывания у клиента?
Давайте разделим вопросы миграции имеющихся данных и структуры БД? миграция она в любом случае есть. И это уже зависит от конретной ситуации. Гдето проще на на одной БД, гдето на другой. Разнится в том числе и в рамках одной линейки.
G>ЗЫ. Уже заметил проблему с тем что не могут люди сказать зачем им нужна NoSQL база кроме "for scaling". Горизонтальная масштабируемость съела моск.
Лично я про scaling ничего не говорил, это вы уже чужие слова мне приписываете.
G>Интересно будет посмотреть куда оно все пойдет когда SSD массово войдут на рынок.
Да
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, cadet354, Вы писали:
C>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, cadet354, Вы писали:
C>>>>Здравствуйте, gandjustas, Вы писали:
G>>>>>Ну вы же понимаете что подавляющее большинство приложений таких проблем не увидит, C>>>>согласен полностью, я уже говорил что для обычных приложений для себя я вижу пользу схема-фрее, а документы расматривать в качестве Agregate root в терминах DDD G>>>Сама концепция агрегатов и рутов — зло. В зависимости от требований рутом может стать то одна запись, то другая. А требования могут меняться со временем. G>>>Например интернет магазин. Рутом можно сделать заказ, но внезапно появляется требование выводить самые продаваемые товары и рутом уже становится Товар. А в другом случае рутом станет пользователь. Таким образом в агрегат попадает или вся база, или надо сущности растаскивать по отдельным "таблицам". C>>ну все в одну сущность засовывать не надо, товар и его характеристики это одна сущность (документ) (сколько таблиц это будет в реляционной модели сам понимаешь) G>Чаще всего одна.
C>>вторая сущность (документ) это заказ со своими характеристиками. G>Позиции заказа являются характеристиками заказа? А если нам нужно считать продажи по товарам за последний месяц?
G>>>Реляционность предполагает регулярную структуру. Для каждого поля тип заранее определен. Это позволяет строить индексы и прозрачно их использовать для оптимизации запросов. C>>бизнес требования могут меняться (нужен был один тлф, а теперь несколько). G>Ну записали в одно поле через запятую
Можно XML хранить. Вообще можно сделать все одной таблицей, с двумя колонками: id и его xml содержимое. Индексы по xml xpath нормальные базы умеют делать. И не нужен никакой NoSQL.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Аноним, Вы писали:
А>>>Здравствуйте, Sinclair, Вы писали:
S>>>>Здравствуйте, Аноним, Вы писали: А>>>>>Даст свободное время на реализацию бизнес логики, т.к. вы престанете заниматься фигней, закручивая гайки растущему организму. А>>>>>В начале нужно делом заниматься. При этом еще не известно какие данные и структуры там будут. Это известно лишь когда проект закончен. Вот когда проект принесет вам миллиард долларов, купите себе остров, вот там тогда до старости можете переписывать на RDBMS, придумывать нормальные формы, индексы, вьюхи и тригеры. S>>>>А по-моему всё строго наоборот. Там, где на RDBMS я могу накидать структуру нормализованной базы и взлететь,
А>>>А откуда вы в начале проекта узнаете какая структура должна быть в конце проекта? Попросите написать 600 страничное ТЗ со всеми ER и ззкесами, и цифрами описываюимим предположительное количество операций каждого вида? Если вам такое предоставят — нужно писать под RDBMS, вы совершенно правы.
G>>А если не предоставят, то тем более нужно под RDBMS писать. Иначе понадобится делать заппросы, на которые изначально не рассчитывал и придется плодить индексы под каждый запрос.
А>Индексы не зависят от типа БД.
Зависят. В RDBMS индесы отличаются от индексов в NoSQL.
А>Чаще всего по началу очень сложно придумать нормальную структуру со всем связми, гораздо проще хранить в разных ячейках разное количество столбцов, по ситуации.
Не понял о чем ты.
А>>>И обратите внимание что NoSQL популярен именно в стартапах. G>>Потому что там традиционно не хватает нормальных программистов СУБД. G>>Ниче что треть программистов, работающих с БД, не понимают что такое индекс? Может это проблема СУБД? А>Это проблема. Проблема того что в стартапе не так много денег. И нанять админа БД, который по факту будет работать несколько часов в месяц, но при этом постоянно ворчать "да что вы все не можете определится с тем какая у вас структура" слишком дорогое удовольствие. Это проблема.
Для разработки не нужен админ БД, сами разработчики должны понимать индексы и подобные вещи в БД, ведь именно они пишут запросы.
А>>>Может потому что программисту удобней описывать классы в коде, просто как как объект его области, как удобней использовать в коде. А с хранением, запросами и прочим ему сейчас некогда заморачиваться. Лишь положил — прочитал, а в какой структуре это будет хранить БД его не касается. G>>Так и с реляционными БД можно.
А>Но мы ведь говорим про удобство и соотношение усилий к результату?
Еще раз: для реляционных бд возможна такая же модель разработки.
А>>>А завтра он поймет что вообще не так писал. Или новый тренд в интернете. Или еще чтото. Он не знает что завтра. Но когда наступит завтра — он легко поправит свой код, а БД под него сама подстроится. G>>Прям сама? Вот хранили авторов статей вместе со статьями, а потом решили отдельно, подстроится?
А>Сама в том смысле что не нужно делать новые запросы, новые меппинги и пр. Ведь никто не мешает хранить в одной таблице разные классы, или разные версии одного класса, или иерархию классов (не в смысле дерева, а в смысле хранить в одной таблице объекты класса Rectangle, Box, Ellipse, которые из учебников про ООП), или класс котором значения полей могут разных типов, при этом не начиная каждый раз придумывать новую систему реляционных связей.
Если все в одном месте хранится, как потом с этим работать?
G>>А как она будет пдстраиваться после развертывания у клиента? А>Давайте разделим вопросы миграции имеющихся данных и структуры БД? миграция она в любом случае есть. И это уже зависит от конретной ситуации. Гдето проще на на одной БД, гдето на другой. Разнится в том числе и в рамках одной линейки.
Миграция структуры без данных вообще не проблема.
G>>ЗЫ. Уже заметил проблему с тем что не могут люди сказать зачем им нужна NoSQL база кроме "for scaling". Горизонтальная масштабируемость съела моск. А>Лично я про scaling ничего не говорил, это вы уже чужие слова мне приписываете.
А я не говорю что это твои слова, просто тенденция.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Аноним, Вы писали:
>> G>Интересно будет посмотреть куда оно все пойдет когда SSD массово войдут на рынок. >> Да
AB>Результат уже известен — профита почти нет, а цена как у самолета — революции не случится.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, Аноним, Вы писали:
А>>>>Здравствуйте, Sinclair, Вы писали:
S>>>>>Здравствуйте, Аноним, Вы писали: А>>>>>>Даст свободное время на реализацию бизнес логики, т.к. вы престанете заниматься фигней, закручивая гайки растущему организму. А>>>>>>В начале нужно делом заниматься. При этом еще не известно какие данные и структуры там будут. Это известно лишь когда проект закончен. Вот когда проект принесет вам миллиард долларов, купите себе остров, вот там тогда до старости можете переписывать на RDBMS, придумывать нормальные формы, индексы, вьюхи и тригеры. S>>>>>А по-моему всё строго наоборот. Там, где на RDBMS я могу накидать структуру нормализованной базы и взлететь,
А>>>>А откуда вы в начале проекта узнаете какая структура должна быть в конце проекта? Попросите написать 600 страничное ТЗ со всеми ER и ззкесами, и цифрами описываюимим предположительное количество операций каждого вида? Если вам такое предоставят — нужно писать под RDBMS, вы совершенно правы.
G>>>А если не предоставят, то тем более нужно под RDBMS писать. Иначе понадобится делать заппросы, на которые изначально не рассчитывал и придется плодить индексы под каждый запрос.
А>>Индексы не зависят от типа БД. G>Зависят. В RDBMS индесы отличаются от индексов в NoSQL.
Я имею ввиду что наличие индексов не зависит. Мы хотим чтото индексировать то мы будем индексировать независимо от типа БД.
А>>Чаще всего по началу очень сложно придумать нормальную структуру со всем связми, гораздо проще хранить в разных ячейках разное количество столбцов, по ситуации. G>Не понял о чем ты.
Вот видимо у нас тут расхождение. Я все это время пытался сказать что в нереляционной БД может лежать что угодно. Пусть некрасиво, ненормализованно, кучей, но что угодно.
Объясню подробней. Вот и тут в форуме тоже постоянно появляются вопросы про то как же хранить информацию о товарах в магазине. Вопрос очень типичный. Я с таким сталкиваюсь не реже раза в месяц.
Возмем, для примера, Яндекс.Маркет, чтобы наглядней было. В категории велосипедов мы выбираем по типу аммортизатора, а в категории компьютеры мы выбираем по типу процессор. Это можно сделать в реляционной БД:
вариант А — сделать по отдельной таблице для каждой категории (дурно пахнущий вариант имхо)
вариант Б — сделать таблицы вида product(id, name) + parameters (id, product_id, name, data_type, value). Будет работать, правда value придется хранить как varchar, и индекс строить по функции от типа данных + значения (никакой нормализации к томуже)
вариант В — А + Б (т.е. дурно пахнущая ненормализованная структура, но в реляционной БД)
вариант С — нормализованный, весь такой реляционный, все типы данных хранятся своим типом, что нужно проиндексировано, ничего лишнего не проиндексировано, в любой момент позволяет добавить новую категорию товаров и т.д. должен быть такой вариант, но я не встречал.
А можно положить в NoSQL бд, в одну таблицу products. Где в одной строке будет 150 колонок с параметрами компьютера, а в другой 15 с параметрами велосипеда. Пред новым годом добавить категорию "подарки", ничего не меняя. Такой вариант для программиста на порядок проще. А простота в стартапе очень важна. Каждая мелочь это барьер. Это очень важно.
А>>>>И обратите внимание что NoSQL популярен именно в стартапах. G>>>Потому что там традиционно не хватает нормальных программистов СУБД. G>>>Ниче что треть программистов, работающих с БД, не понимают что такое индекс? Может это проблема СУБД? А>>Это проблема. Проблема того что в стартапе не так много денег. И нанять админа БД, который по факту будет работать несколько часов в месяц, но при этом постоянно ворчать "да что вы все не можете определится с тем какая у вас структура" слишком дорогое удовольствие. Это проблема. G>Для разработки не нужен админ БД, сами разработчики должны понимать индексы и подобные вещи в БД, ведь именно они пишут запросы.
В нормальных стартапах люди очень хорошо понимают индексы. Честно говоря не видел прямой корреляции между "стартапом" и "тупыми разработчиками", и даже наоборот интуитивно кажется что есть обратная, но не замерял.
В общем не надо путать с ПХПшниками с free-lance.ru А вообще имхо эта подветка уже не имеет отношения к NoSQL
А>>>>Может потому что программисту удобней описывать классы в коде, просто как как объект его области, как удобней использовать в коде. А с хранением, запросами и прочим ему сейчас некогда заморачиваться. Лишь положил — прочитал, а в какой структуре это будет хранить БД его не касается. G>>>Так и с реляционными БД можно.
Можно. Но как я выше показал — заставляет делать лишние телодвижения.
А>>Но мы ведь говорим про удобство и соотношение усилий к результату? G>Еще раз: для реляционных бд возможна такая же модель разработки.
Возможна. В обратную сторону тоже верно. И тут нет никакого противоречия. Можно и в тетрадке хранить все. Можно ведь?
Я про стоимость, про то что не всегда все решения равноценны.
А>>>>А завтра он поймет что вообще не так писал. Или новый тренд в интернете. Или еще чтото. Он не знает что завтра. Но когда наступит завтра — он легко поправит свой код, а БД под него сама подстроится. G>>>Прям сама? Вот хранили авторов статей вместе со статьями, а потом решили отдельно, подстроится?
А>>Сама в том смысле что не нужно делать новые запросы, новые меппинги и пр. Ведь никто не мешает хранить в одной таблице разные классы, или разные версии одного класса, или иерархию классов (не в смысле дерева, а в смысле хранить в одной таблице объекты класса Rectangle, Box, Ellipse, которые из учебников про ООП), или класс котором значения полей могут разных типов, при этом не начиная каждый раз придумывать новую систему реляционных связей. G>Если все в одном месте хранится, как потом с этим работать?
Не сталкивался с проблемой. У программиста обычно и так уже есть несколько классов в программе. От того что он их сохранил и прочитал сложности не добавилось.
G>>>А как она будет пдстраиваться после развертывания у клиента? А>>Давайте разделим вопросы миграции имеющихся данных и структуры БД? миграция она в любом случае есть. И это уже зависит от конретной ситуации. Гдето проще на на одной БД, гдето на другой. Разнится в том числе и в рамках одной линейки. G>Миграция структуры без данных вообще не проблема.
Как минимум требует переписывания sql запросов.
G>>>ЗЫ. Уже заметил проблему с тем что не могут люди сказать зачем им нужна NoSQL база кроме "for scaling". Горизонтальная масштабируемость съела моск. А>>Лично я про scaling ничего не говорил, это вы уже чужие слова мне приписываете. G>А я не говорю что это твои слова, просто тенденция.
Наверное потому что это действительно на поверхности и действительно проблема для реляционных БД
Но, раз уж от одного открестился, выделил бы именно гибкость разработки и возможность оптимизации под конкретну задачу.
В общем случае оно тоже не будет оптимально. Но в некоторых случаях на порядки быстрее, как примере по ссылке выше что я привел. Было что переписывали из ораклового решения на NoSQLный Kdb+, что сократило некоторые важные отчеты с нескольких часов до секунд. Т.е. чуть ли не рилтайм анализ, можете представить как повлияло на бизнес процессы.
Реляционность и нормальные формы это хорошо и красиво, но отнюдь не серебряная пуля, нужно понимать задачу и выбирать то что будет оптимальней (= стоимость поддержки / стоимость разработки) а стоимость разработки =~ n ^ количество препятствий
ps в nosql тоже полно проблем, самая главная из которых это большой порог вхождения в каждое индивидуальное решение / отсутствие единого стандарта хотя бы на язык запросов. И проблема эта не решаемая, в силу своей сути эти хранилишь.
А>Объясню подробней. Вот и тут в форуме тоже постоянно появляются вопросы про то как же хранить информацию о товарах в магазине. Вопрос очень типичный. Я с таким сталкиваюсь не реже раза в месяц. А>Возмем, для примера, Яндекс.Маркет, чтобы наглядней было. В категории велосипедов мы выбираем по типу аммортизатора, а в категории компьютеры мы выбираем по типу процессор. Это можно сделать в реляционной БД: А> вариант А — сделать по отдельной таблице для каждой категории (дурно пахнущий вариант имхо) А> вариант Б — сделать таблицы вида product(id, name) + parameters (id, product_id, name, data_type, value). Будет работать, правда value придется хранить как varchar, и индекс строить по функции от типа данных + значения (никакой нормализации к томуже) А> вариант В — А + Б (т.е. дурно пахнущая ненормализованная структура, но в реляционной БД) А> вариант С — нормализованный, весь такой реляционный, все типы данных хранятся своим типом, что нужно проиндексировано, ничего лишнего не проиндексировано, в любой момент позволяет добавить новую категорию товаров и т.д. должен быть такой вариант, но я не встречал.
А>А можно положить в NoSQL бд, в одну таблицу products. Где в одной строке будет 150 колонок с параметрами компьютера, а в другой 15 с параметрами велосипеда. Пред новым годом добавить категорию "подарки", ничего не меняя. Такой вариант для программиста на порядок проще. А простота в стартапе очень важна. Каждая мелочь это барьер. Это очень важно.
такой маразм можно и в обычном MS_SQL-е сделать, распихав все XML или в sparse columns,
Будет быстрее проще и надежнее, чем копаться в опенсорсных поделках сомнительного качества
И вообще говоря — это задача на битовые индексы, как ее решать было известно еще до того как компы появились
А>Как минимум требует переписывания sql запросов.
и что? язык декларативный, проще уже некуда
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: NoSQL vs RDBMS
От:
Аноним
Дата:
08.10.10 06:55
Оценка:
Здравствуйте, rm822, Вы писали:
А>>Объясню подробней. Вот и тут в форуме тоже постоянно появляются вопросы про то как же хранить информацию о товарах в магазине. Вопрос очень типичный. Я с таким сталкиваюсь не реже раза в месяц. А>>Возмем, для примера, Яндекс.Маркет, чтобы наглядней было. В категории велосипедов мы выбираем по типу аммортизатора, а в категории компьютеры мы выбираем по типу процессор. Это можно сделать в реляционной БД: А>> вариант А — сделать по отдельной таблице для каждой категории (дурно пахнущий вариант имхо) А>> вариант Б — сделать таблицы вида product(id, name) + parameters (id, product_id, name, data_type, value). Будет работать, правда value придется хранить как varchar, и индекс строить по функции от типа данных + значения (никакой нормализации к томуже) А>> вариант В — А + Б (т.е. дурно пахнущая ненормализованная структура, но в реляционной БД) А>> вариант С — нормализованный, весь такой реляционный, все типы данных хранятся своим типом, что нужно проиндексировано, ничего лишнего не проиндексировано, в любой момент позволяет добавить новую категорию товаров и т.д. должен быть такой вариант, но я не встречал.
А>>А можно положить в NoSQL бд, в одну таблицу products. Где в одной строке будет 150 колонок с параметрами компьютера, а в другой 15 с параметрами велосипеда. Пред новым годом добавить категорию "подарки", ничего не меняя. Такой вариант для программиста на порядок проще. А простота в стартапе очень важна. Каждая мелочь это барьер. Это очень важно.
R>такой маразм можно и в обычном MS_SQL-е сделать, распихав все XML или в sparse columns,
А зачем? Зачем тогда реляционна БД?
Почему всегда (всегда!) в споре NoSQL vs SQL всегда прибегает умник и говорит что всегда все можно хранить в виде XML и в одной таблице? Неужто в своих словах сам не замечает противоречия?
R>Будет быстрее проще и надежнее, чем копаться в опенсорсных поделках сомнительного качества
Реляционные БД тоже бывают опенсорсными. nosql бд тоже бывают коммерчески закрытыми. К чему вы это сказали? Вы про какие именно виды опенсорсных БД говрили? про кривые опенсорсные nosql или про кривые опенсорсные sql? Пользуйтесь прямыми закрытыми БД. В чем проблема то?
R>И вообще говоря — это задача на битовые индексы, как ее решать было известноеще до того как компы появились
Ктото утверждал что задача не имеет решения? Или ктото утверждал что это другая задача? С чем именно вы этим высказыванием хотели поспорить?
А>>Как минимум требует переписывания sql запросов. R>и что? язык декларативный, проще уже некуда
Да, простой. А что именно это меняет?
Re: NoSQL vs RDBMS
От:
Аноним
Дата:
08.10.10 07:23
Оценка:
Вопрос к адептам nosql.
Может ли данная технология помочь мне в построении банерокрутилки ?
Суть примерно вот в чём: надо обеспечить огромное показов разных банеров в рекламной сети ( состоящей из, соответственно кучи площадок-сайтов ). Например в секунду надо "отдавать" 1000 банеров.
Показ каждого банера — это ( в терминах РСУБД ) как минимум 2 запроса.
1й — взять нужный банер из базы ( отдается с учетом кучи выставленных таргетингов — по времени/географии/кол-ву показов/переходов и проч. , т.е. довольно тяжелый запрос)
2й — запись в статистику.
Понятно, что эти 2 можно объединить в 1 с помощью процедуры. Разбиение чисто логическое.
Причем система должна легко масштабироваться в сторону многократного увеличения нагрузки.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Аноним, Вы писали:
А>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Здравствуйте, Аноним, Вы писали:
А>>>>>Здравствуйте, Sinclair, Вы писали:
S>>>>>>Здравствуйте, Аноним, Вы писали: А>>>>>>>Даст свободное время на реализацию бизнес логики, т.к. вы престанете заниматься фигней, закручивая гайки растущему организму. А>>>>>>>В начале нужно делом заниматься. При этом еще не известно какие данные и структуры там будут. Это известно лишь когда проект закончен. Вот когда проект принесет вам миллиард долларов, купите себе остров, вот там тогда до старости можете переписывать на RDBMS, придумывать нормальные формы, индексы, вьюхи и тригеры. S>>>>>>А по-моему всё строго наоборот. Там, где на RDBMS я могу накидать структуру нормализованной базы и взлететь,
А>>>>>А откуда вы в начале проекта узнаете какая структура должна быть в конце проекта? Попросите написать 600 страничное ТЗ со всеми ER и ззкесами, и цифрами описываюимим предположительное количество операций каждого вида? Если вам такое предоставят — нужно писать под RDBMS, вы совершенно правы.
G>>>>А если не предоставят, то тем более нужно под RDBMS писать. Иначе понадобится делать заппросы, на которые изначально не рассчитывал и придется плодить индексы под каждый запрос.
А>>>Индексы не зависят от типа БД. G>>Зависят. В RDBMS индесы отличаются от индексов в NoSQL.
А>Я имею ввиду что наличие индексов не зависит. Мы хотим чтото индексировать то мы будем индексировать независимо от типа БД.
Ты неправ, в NoSQL индексы сильно по-другому работают.
А>>>Чаще всего по началу очень сложно придумать нормальную структуру со всем связми, гораздо проще хранить в разных ячейках разное количество столбцов, по ситуации. G>>Не понял о чем ты.
А>Вот видимо у нас тут расхождение. Я все это время пытался сказать что в нереляционной БД может лежать что угодно. Пусть некрасиво, ненормализованно, кучей, но что угодно.
И в реляционной тоже.
Но ты ведь работаешь не с "чем угодно". Ты всегда ожидаешь какую-то структуру.
А>Объясню подробней. Вот и тут в форуме тоже постоянно появляются вопросы про то как же хранить информацию о товарах в магазине. Вопрос очень типичный. Я с таким сталкиваюсь не реже раза в месяц. А>Возмем, для примера, Яндекс.Маркет, чтобы наглядней было. В категории велосипедов мы выбираем по типу аммортизатора, а в категории компьютеры мы выбираем по типу процессор. Это можно сделать в реляционной БД: А> вариант А — сделать по отдельной таблице для каждой категории (дурно пахнущий вариант имхо) А> вариант Б — сделать таблицы вида product(id, name) + parameters (id, product_id, name, data_type, value). Будет работать, правда value придется хранить как varchar, и индекс строить по функции от типа данных + значения (никакой нормализации к томуже) А> вариант В — А + Б (т.е. дурно пахнущая ненормализованная структура, но в реляционной БД) А> вариант С — нормализованный, весь такой реляционный, все типы данных хранятся своим типом, что нужно проиндексировано, ничего лишнего не проиндексировано, в любой момент позволяет добавить новую категорию товаров и т.д. должен быть такой вариант, но я не встречал.
А>А можно положить в NoSQL бд, в одну таблицу products. Где в одной строке будет 150 колонок с параметрами компьютера, а в другой 15 с параметрами велосипеда. Пред новым годом добавить категорию "подарки", ничего не меняя. Такой вариант для программиста на порядок проще. А простота в стартапе очень важна. Каждая мелочь это барьер. Это очень важно.
Детский сад. Положить то ты можешь, а как ты потом будешь обрабатывать? Программа, обрабатывающая твои данные, должна знать структуру этих данных в том или ином виде. Особенно это важно для ввода данных.
В РБД все хорошо с этим. Структурированная часть данных становится полями таблиц, а неструктурированная или полуструктурированная укладываются соответственно в блобы или xml поля. Современные субд умеют проверять xml по схеме, индексировать xml для ускорения запросов, а полнотекстовый поиск, встроенный в БД, работает как xml, так и с блобами. Для MS SQL можно написать свой фильтр например для поиска по метаданным картинок в блобах.
Твой пример с магазином.
Делаем таблицы для типов товаров они в xml хранят xsd схему для каждого типа. В таблице товаров создаем поля Цнеа, Производитель, Тип итп, а все остальное укладываем в xml. Можно к xml прицепить схемы и xml будет проверяться.
В приложении по схеме вполне можно сгененрировать интерфейс для редактирования товара, а также динамически создавать типы товаров. А также по схеме можно сгенерировать интерфейс для подбора товара по параметрам.
А теперь вопрос. Как ты с NoSQL будешь делать редактирование и подбор товаров? А>>>>>И обратите внимание что NoSQL популярен именно в стартапах. G>>>>Потому что там традиционно не хватает нормальных программистов СУБД. G>>>>Ниче что треть программистов, работающих с БД, не понимают что такое индекс? Может это проблема СУБД? А>>>Это проблема. Проблема того что в стартапе не так много денег. И нанять админа БД, который по факту будет работать несколько часов в месяц, но при этом постоянно ворчать "да что вы все не можете определится с тем какая у вас структура" слишком дорогое удовольствие. Это проблема. G>>Для разработки не нужен админ БД, сами разработчики должны понимать индексы и подобные вещи в БД, ведь именно они пишут запросы.
А>В нормальных стартапах люди очень хорошо понимают индексы. Честно говоря не видел прямой корреляции между "стартапом" и "тупыми разработчиками", и даже наоборот интуитивно кажется что есть обратная, но не замерял. А>В общем не надо путать с ПХПшниками с free-lance.ru А вообще имхо эта подветка уже не имеет отношения к NoSQL
А>>>>>Может потому что программисту удобней описывать классы в коде, просто как как объект его области, как удобней использовать в коде. А с хранением, запросами и прочим ему сейчас некогда заморачиваться. Лишь положил — прочитал, а в какой структуре это будет хранить БД его не касается. G>>>>Так и с реляционными БД можно. А>Можно. Но как я выше показал — заставляет делать лишние телодвижения.
Ты только свое непонимание проблемы показал.
А>>>Но мы ведь говорим про удобство и соотношение усилий к результату? G>>Еще раз: для реляционных бд возможна такая же модель разработки.
А>Возможна. В обратную сторону тоже верно. И тут нет никакого противоречия. Можно и в тетрадке хранить все. Можно ведь?
Это тут причем?
А>Я про стоимость, про то что не всегда все решения равноценны.
Стоимость чего?
А>>>>>А завтра он поймет что вообще не так писал. Или новый тренд в интернете. Или еще чтото. Он не знает что завтра. Но когда наступит завтра — он легко поправит свой код, а БД под него сама подстроится. G>>>>Прям сама? Вот хранили авторов статей вместе со статьями, а потом решили отдельно, подстроится?
А>>>Сама в том смысле что не нужно делать новые запросы, новые меппинги и пр. Ведь никто не мешает хранить в одной таблице разные классы, или разные версии одного класса, или иерархию классов (не в смысле дерева, а в смысле хранить в одной таблице объекты класса Rectangle, Box, Ellipse, которые из учебников про ООП), или класс котором значения полей могут разных типов, при этом не начиная каждый раз придумывать новую систему реляционных связей. G>>Если все в одном месте хранится, как потом с этим работать?
А>Не сталкивался с проблемой. У программиста обычно и так уже есть несколько классов в программе. От того что он их сохранил и прочитал сложности не добавилось.
А что мне мешает тоже самое сделать с РСУБД? Я с помощью EF могу сделать тоже самое — имея несколько классов сохранить их в БД и прочитать оттуда.
G>>>>А как она будет пдстраиваться после развертывания у клиента? А>>>Давайте разделим вопросы миграции имеющихся данных и структуры БД? миграция она в любом случае есть. И это уже зависит от конретной ситуации. Гдето проще на на одной БД, гдето на другой. Разнится в том числе и в рамках одной линейки. G>>Миграция структуры без данных вообще не проблема.
А>Как минимум требует переписывания sql запросов.
Не требует.
Например у меня есть запрос
select A,B,C from T
Он работает пока не будет удалено одно из полей A\B\С. Если я читаю поле, значит в дальнейшем как-то обрабатываю его в программе.
С NoSQL аналогично, ты читаешь из базы данных че-то и рассчитываешь что у этого чего-то есть определенный набор полей (а чаще всего и определенного типа). Если вдруг одного из полей не стало, то у тебя точно такие же проблемы.
G>>>>ЗЫ. Уже заметил проблему с тем что не могут люди сказать зачем им нужна NoSQL база кроме "for scaling". Горизонтальная масштабируемость съела моск. А>>>Лично я про scaling ничего не говорил, это вы уже чужие слова мне приписываете. G>>А я не говорю что это твои слова, просто тенденция.
А>Наверное потому что это действительно на поверхности и действительно проблема для реляционных БД
В теории да, на практике с этим сталкиваются единицы.
А>Но, раз уж от одного открестился, выделил бы именно гибкость разработки и возможность оптимизации под конкретну задачу.
В чем гибкость? И где ты увидел возможности оптимизации?
Повторяя эти слова ты не пытаешься понять сути проблем при работе с данными.
Я в первом посте этой темы привел юзкейсы. Покажи на них "гибкость" и "возможность оптимизации под конкретну задачу".
А>В общем случае оно тоже не будет оптимально. Но в некоторых случаях на порядки быстрее, как примере по ссылке выше что я привел. Было что переписывали из ораклового решения на NoSQLный Kdb+, что сократило некоторые важные отчеты с нескольких часов до секунд. Т.е. чуть ли не рилтайм анализ, можете представить как повлияло на бизнес процессы.
Круто, я и на РСУБД сокращал время в тысячи раз. Буквально одним индексом.
Здравствуйте, Аноним, Вы писали:
А>Почему всегда (всегда!) в споре NoSQL vs SQL всегда прибегает умник и говорит что всегда все можно хранить в виде XML и в одной таблице? Неужто в своих словах сам не замечает противоречия?
Прикол в том что в SQL не обязательно все хранить в XML там можно (и нужно) хранить только слабоструктурированную часть данных.
А вот если основная масса обращений идет именно к слабоструктурированной части, тогда уже можно думать о документной БД.
Здравствуйте, Аноним, Вы писали:
> Возмем, для примера, Яндекс.Маркет, чтобы наглядней было. В категории велосипедов мы выбираем по типу аммортизатора, а в категории компьютеры мы выбираем по типу процессор. Это можно сделать в реляционной БД:
[...] > А можно положить в NoSQL бд, в одну таблицу products.
А можно скрестить реляционки (на "грязную" работу по начальной обработке и хранению "сырников") и NoSQL (который будет работать на продакшине)
Здравствуйте, Аноним, Вы писали:
А>В общем случае оно тоже не будет оптимально. Но в некоторых случаях на порядки быстрее, как примере по ссылке выше что я привел. Было что переписывали из ораклового решения на NoSQLный Kdb+, что сократило некоторые важные отчеты с нескольких часов до секунд. Т.е. чуть ли не рилтайм анализ, можете представить как повлияло на бизнес процессы.
Я тоже знаю решения на Оракле с отчетами по несколько часов. И? Плохую программу можно написать на любом языке. Видно сразу, с Ораклом работали ламеры.
Здравствуйте, gandjustas, Вы писали:
G>Подход RDB очевиден: G>1)создать нормализованные таблицы G>2)сделать индексированные view, считающие количество голосов по ответам, комментам, пользователям G>3)Сделать индексированное view для подсчета количества ответов и голосов по вопросам G>4)В случае невозможности сделать view — пересчитывать в триггерах G>5)Понаделать индексов чтобы не было ни одного scan для выборки
G>Такая БД влезет примерно в 100 гб (в зависимости от длины вопросов и ответов). Один хороший сервак должен потянуть такую базу.
G>Что нам предложит NoSQL подход в данном случае?
Здравствуйте, Аноним, Вы писали:
А>>>А можно положить в NoSQL бд, в одну таблицу products. Где в одной строке будет 150 колонок с параметрами компьютера, а в другой 15 с параметрами велосипеда. Пред новым годом добавить категорию "подарки", ничего не меняя. Такой вариант для программиста на порядок проще. А простота в стартапе очень важна. Каждая мелочь это барьер. Это очень важно.
R>>такой маразм можно и в обычном MS_SQL-е сделать, распихав все XML или в sparse columns,
А>А зачем? Зачем тогда реляционна БД?
Хе-хе. salesforce так работает. Только там одна таблица не со 150, а с 500 колонок.
Здравствуйте, Аноним, Вы писали:
А>Может ли данная технология помочь мне в построении банерокрутилки ?
Нет. Баннерокрутилка с прямым доступом в базу ляжет еще раньше чем взлетит, независимо от того будет там NoSQL или RDBMS. На тему того, как устроены баннерокрутилки было несколько неплохих докладов на HighLoad++.
