Есть всем известный сайт stackoverflow.com
Возмем его упрощенную структуру: пользователи, вопросы, ответы, комменты, голоса, связи надеюсь понятны.
Надо спроектировать БД так чтобы она могла выдержать больше объемы, сравнимые с самим stackoverflow. Это около миллиона вопросов, 50 тыщ активных пользователей, 10 миллионов ответов и столько же комментов, 10 миллионов голосов.
Функционал как на сайте — список последних вопросов, список популярных вопросов, список неотвеченных вопросов, вопрос с ответами и комментами с сортировкой по ответам (дата, количество голосов), статистика пользователя: что когда где написал, прокомментил, проголосовал. Ну и сами действия: написание\правка вопроса, ответа, коммента, голосование.
Полнотекстовый поиск отдаем внешнему компоненту, типа lucene или google\bing.
Подход RDB очевиден:
1)создать нормализованные таблицы
2)сделать индексированные view, считающие количество голосов по ответам, комментам, пользователям
3)Сделать индексированное view для подсчета количества ответов и голосов по вопросам
4)В случае невозможности сделать view — пересчитывать в триггерах
5)Понаделать индексов чтобы не было ни одного scan для выборки
Такая БД влезет примерно в 100 гб (в зависимости от длины вопросов и ответов). Один хороший сервак должен потянуть такую базу.
Здравствуйте, gandjustas, Вы писали:
g> Есть всем известный сайт stackoverflow.com g> 50 тыщ активных пользователей, 10 миллионов ответов и столько же комментов, 10 миллионов голосов. g> Такая БД влезет примерно в 100 гб (в зависимости от длины вопросов и ответов).
Ну со 100 гигами ты загрубил — меньше, где-то 25 сырых данных, если не учитывать реплики.
g> Что нам предложит NoSQL подход в данном случае?
ИМХО, ничего — задача сильно тривиальна и хорошо типизирована для реляционных БД + memcached — типичная ВИО.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, gandjustas, Вы писали:
g>> Есть всем известный сайт stackoverflow.com g>> 50 тыщ активных пользователей, 10 миллионов ответов и столько же комментов, 10 миллионов голосов. g>> Такая БД влезет примерно в 100 гб (в зависимости от длины вопросов и ответов).
AB>Ну со 100 гигами ты загрубил — меньше, где-то 25 сырых данных, если не учитывать реплики.
это верхняя планка для очень больших вопросов и ответов
g>> Что нам предложит NoSQL подход в данном случае? AB>ИМХО, ничего — задача сильно тривиальна и хорошо типизирована для реляционных БД + memcached — типичная ВИО.
В этом форуме видел высказывания что NoSQL всехподряд рвет. Вот интересно как NoSQL будет выглядеть на такой (довольной типовой для веба) задаче.
Если сложно для такой, то можно привести другой реальный пример (другой сайт), где NoSQL будет выглядеть хорошо.
Здравствуйте, gandjustas, Вы писали:
g> В этом форуме видел высказывания что NoSQL всехподряд рвет. Вот интересно как NoSQL будет выглядеть на такой (довольной типовой для веба) задаче.
Скорее всего так же или несколько хуже. Сила NoSQL проявляется на больших объемах данных (TB, PB) или на особенности данных.
g> Если сложно для такой, то можно привести другой реальный пример (другой сайт), где NoSQL будет выглядеть хорошо.
Например, сайт типа "МоеДело" — для него документо-ориентированная БД подошла бы очень хорошо (что они используют в реальности я без понятия).
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, gandjustas, Вы писали:
g>> В этом форуме видел высказывания что NoSQL всехподряд рвет. Вот интересно как NoSQL будет выглядеть на такой (довольной типовой для веба) задаче. AB>Скорее всего так же или несколько хуже. Сила NoSQL проявляется на больших объемах данных (TB, PB) или на особенности данных.
То есть почти для всех программ NoSQL не подходит, так?
g>> Если сложно для такой, то можно привести другой реальный пример (другой сайт), где NoSQL будет выглядеть хорошо.
AB>Например, сайт типа "МоеДело" — для него документо-ориентированная БД подошла бы очень хорошо (что они используют в реальности я без понятия).
Я пользуюсь сайтом, с чего бы там такая база подошла?
Здравствуйте, gandjustas, Вы писали:
g>>> В этом форуме видел высказывания что NoSQL всехподряд рвет. Вот интересно как NoSQL будет выглядеть на такой (довольной типовой для веба) задаче. AB>>Скорее всего так же или несколько хуже. Сила NoSQL проявляется на больших объемах данных (TB, PB) или на особенности данных. G>То есть почти для всех программ NoSQL не подходит, так? g>>> Если сложно для такой, то можно привести другой реальный пример (другой сайт), где NoSQL будет выглядеть хорошо.
Тот же StackOverflow. Но теперь с системой обнаружения похожих вопросов, конфигурируемых пользователями формами, и real-time оповещенияим.
Здравствуйте, gandjustas, Вы писали:
G>Подход RDB очевиден: G>1)создать нормализованные таблицы G>2)сделать индексированные view, считающие количество голосов по ответам, комментам, пользователям G>3)Сделать индексированное view для подсчета количества ответов и голосов по вопросам
Вот индексированные view — это и есть NoSQL, видом сбоку.
G>4)В случае невозможности сделать view — пересчитывать в триггерах G>5)Понаделать индексов чтобы не было ни одного scan для выборки
С многими полнотекстовыми алгоритмами фигня выходит.
Здравствуйте, gandjustas, Вы писали:
G>Если сложно для такой, то можно привести другой реальный пример (другой сайт), где NoSQL будет выглядеть хорошо.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
g>>>> В этом форуме видел высказывания что NoSQL всехподряд рвет. Вот интересно как NoSQL будет выглядеть на такой (довольной типовой для веба) задаче. AB>>>Скорее всего так же или несколько хуже. Сила NoSQL проявляется на больших объемах данных (TB, PB) или на особенности данных. G>>То есть почти для всех программ NoSQL не подходит, так? g>>>> Если сложно для такой, то можно привести другой реальный пример (другой сайт), где NoSQL будет выглядеть хорошо. C>Тот же StackOverflow.
А базовые кейсы?
C>Но теперь с системой обнаружения похожих вопросов
Это вопрос индексации, а никак не хранения.
C>конфигурируемых пользователями формами, и real-time оповещенияим.
А тут NoSQL причем? Как это вообще с системами хранения связано?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Подход RDB очевиден: G>>1)создать нормализованные таблицы G>>2)сделать индексированные view, считающие количество голосов по ответам, комментам, пользователям G>>3)Сделать индексированное view для подсчета количества ответов и голосов по вопросам C>Вот индексированные view — это и есть NoSQL, видом сбоку.
Ну бред же. Ты еще скажи что сами индексы тоже NoSQL, видом сбоку.
1)NoSQL не поддерживает join, вместо каждого join надо писать индекс на сервере
2)Нету проекции, другая гранулярность изменения\добавления
3)Нету индексов в понимании RDBMS, которые работают автоматически и не требуют явного обращения к ним.
Это самые яркие отличия, которые как раз и влияют на архитектуру.
G>>4)В случае невозможности сделать view — пересчитывать в триггерах G>>5)Понаделать индексов чтобы не было ни одного scan для выборки C>С многими полнотекстовыми алгоритмами фигня выходит.
Полнотекстовый поиск стоит совершенно сбоку от системы хранения.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, gandjustas, Вы писали:
G>>Если сложно для такой, то можно привести другой реальный пример (другой сайт), где NoSQL будет выглядеть хорошо.
CS>gmail и ему подобные например.
Ну юзкейсы в студию, посмотрим.
Реально интересно, hype больший вокруг NoSQL, но примеров почти нету.
Все что нашел:
1)Использование для хранения слабоструктурированных данных (из за того что все NoSQL базы без схемы работают)
2)Использование для очень больших объемов, тут очевидно, так как в RDB не стоит делать распределенные джоины. Поэтому и для RDB приходится использовать подходы NoSQL.
Но это далеко не то чем занимаются большая часть разработчиков.
Здравствуйте, gandjustas, Вы писали:
C>>Вот индексированные view — это и есть NoSQL, видом сбоку. G>Ну бред же. Ты еще скажи что сами индексы тоже NoSQL, видом сбоку. G>1)NoSQL не поддерживает join, вместо каждого join надо писать индекс на сервере
NoSQL бывает разный. Есть и с join'ами, просто они не являются основой, в отличие от РСУБД.
G>2)Нету проекции, другая гранулярность изменения\добавления
Где "нету проекции"? У некоторых NoSQL она ещё погранулярнее большинства РСУБД будет.
C>>С многими полнотекстовыми алгоритмами фигня выходит. G>Полнотекстовый поиск стоит совершенно сбоку от системы хранения.
Ну-ну.
Здравствуйте, gandjustas, Вы писали:
g>>>>> Если сложно для такой, то можно привести другой реальный пример (другой сайт), где NoSQL будет выглядеть хорошо. C>>Тот же StackOverflow. G>А базовые кейсы?
Уже описал.
C>>Но теперь с системой обнаружения похожих вопросов G>Это вопрос индексации, а никак не хранения.
Ага. Ведь всё решается одним индексом.
Как будешь банальное облако тэгов строить?
C>>конфигурируемых пользователями формами, и real-time оповещенияим. G>А тут NoSQL причем? Как это вообще с системами хранения связано?
А ты подумай.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Вот индексированные view — это и есть NoSQL, видом сбоку. G>>Ну бред же. Ты еще скажи что сами индексы тоже NoSQL, видом сбоку. G>>1)NoSQL не поддерживает join, вместо каждого join надо писать индекс на сервере C>NoSQL бывает разный. Есть и с join'ами, просто они не являются основой, в отличие от РСУБД.
Ссылку?
G>>2)Нету проекции, другая гранулярность изменения\добавления C>Где "нету проекции"? У некоторых NoSQL она ещё погранулярнее большинства РСУБД будет.
Ссылку?
C>>>С многими полнотекстовыми алгоритмами фигня выходит. G>>Полнотекстовый поиск стоит совершенно сбоку от системы хранения. C>Ну-ну.
Ты с чем не согласен?
Я часто для полнотекстового поиска использую Lucene.net, храню при этом все в РБД.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
g>>>>>> Если сложно для такой, то можно привести другой реальный пример (другой сайт), где NoSQL будет выглядеть хорошо. C>>>Тот же StackOverflow. G>>А базовые кейсы? C>Уже описал.
Что описал? как ты будешь на NoSQL базовые юзкейсы StackOverflow реализовывать?
C>>>Но теперь с системой обнаружения похожих вопросов G>>Это вопрос индексации, а никак не хранения. C>Ага. Ведь всё решается одним индексом.
Пофиг как решается на самом деле, это совершенно ортогонально системам хранения.
Даже не хочу говорить об этом.
C>Как будешь банальное облако тэгов строить?
В этом есть проблема? Таблица тегов, материализованные view с количеством.
просто чтобы count не считать при запросе.
Много раз уже такое делал.
А ты как будешь делать на NoSQL те юзкейсы, которые я описал в первом посте, и облако тегов заодно?
C>>>конфигурируемых пользователями формами, и real-time оповещенияим. G>>А тут NoSQL причем? Как это вообще с системами хранения связано? C>А ты подумай.
Не, давай ты рассказывай. Как real-time оповещения связаны с NoSQL\RDBMS?
Здравствуйте, gandjustas, Вы писали:
C>>Уже описал. G>Что описал? как ты будешь на NoSQL базовые юзкейсы StackOverflow реализовывать?
А какие проблемы-то? То что решается стандартными join'ами ими и будет решаться. А для более тяжёлых задач — NoSQL.
C>>>>Но теперь с системой обнаружения похожих вопросов G>>>Это вопрос индексации, а никак не хранения. C>>Ага. Ведь всё решается одним индексом. G>Пофиг как решается на самом деле, это совершенно ортогонально системам хранения. G>Даже не хочу говорить об этом.
Да-да.
C>>Как будешь банальное облако тэгов строить? G>В этом есть проблема? Таблица тегов, материализованные view с количеством.
Не, ну ты смешной. Вот у тебя статья, у неё набор тэгов. Как ты их будешь хранить? Как ты будешь строить облака тэгов?
Сразу могу сказать, что на RDBMS нет хорошего решения. Приходится городить огород с триггерами и видами, получая в итоге тот же NoSQL видом сбоку, но только кривой и уродливый.
Кстати, упомянутый тобой Lucene — это абсолютно типичный пример подхода NoSQL. Попробуй её реализовать с помощью индексированных видов?
G>>>А тут NoSQL причем? Как это вообще с системами хранения связано? C>>А ты подумай. G>Не, давай ты рассказывай. Как real-time оповещения связаны с NoSQL\RDBMS?
Очень просто. К примеру, клиенты, получающие оповещения, не могут обращаться к БД по получении сообщения. Иначе оно всё умирает.
Надо как-то хранить в каком-то очень быстром/распределённом кэше то, что они должны получить.
Здравствуйте, gandjustas, Вы писали:
G>>>1)NoSQL не поддерживает join, вместо каждого join надо писать индекс на сервере C>>NoSQL бывает разный. Есть и с join'ами, просто они не являются основой, в отличие от РСУБД. G>Ссылку?
В том же CouchDB делаешь простые табличные виды данных, и джойнишь их в ad-hoc запросах. В MongoDB описываешь связи с помощью http://www.mongodb.org/display/DOCS/Database+References#DatabaseReferences-DBRef и джойнишь по ним.
G>>>2)Нету проекции, другая гранулярность изменения\добавления C>>Где "нету проекции"? У некоторых NoSQL она ещё погранулярнее большинства РСУБД будет. G>Ссылку? http://hypertable.org/ — тут вообще многомерные записи, что-то типа Cache'.
C>>>>С многими полнотекстовыми алгоритмами фигня выходит. G>>>Полнотекстовый поиск стоит совершенно сбоку от системы хранения. C>>Ну-ну. G>Ты с чем не согласен? G>Я часто для полнотекстового поиска использую Lucene.net, храню при этом все в РБД.
Вот Lucene — это и есть типичный пример NoSQL. Так как её функциональность в рамках обычной РСУБД нормально не реализуется.
А NoSQL базы — это можно считать неким фреймворком для создания система типа Lucene.
Здравствуйте, gandjustas, Вы писали:
g> То есть почти для всех программ NoSQL не подходит, так?
Почти для всех программ, нет необходимости даже в отношениях — достаточно key-value хранилища (классический пример Berkeley DB).
g> Я пользуюсь сайтом, с чего бы там такая база подошла? g> Нарисуй упрощенно юзкейсы, посмотрим.
Документы могут иметь различное количество аттрибутов, аттрибуты в свою очередь тоже и т.д. — т.е. как раз та самая нечеткая схема, о которой ты говорил выше. Юзкесы вытекают.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Уже описал. G>>Что описал? как ты будешь на NoSQL базовые юзкейсы StackOverflow реализовывать? C>А какие проблемы-то? То что решается стандартными join'ами ими и будет решаться. А для более тяжёлых задач — NoSQL.
Количество более тяжелых задач очень мало и там видимо не в самом применении NoSQL преимущества, а в способе распределения БД.
Которое еще и упирается в CAP theorem.
C>>>Как будешь банальное облако тэгов строить? G>>В этом есть проблема? Таблица тегов, материализованные view с количеством. C>Не, ну ты смешной. Вот у тебя статья, у неё набор тэгов. Как ты их будешь хранить? Как ты будешь строить облака тэгов?
Связь много-ко-многим таблицы статей и тегов, индескированное представление для тегов, считающее количество использований тега.
Для постоения облака — получаем все теги с количеством если оно больше нуля и строим.
C>Сразу могу сказать, что на RDBMS нет хорошего решения. Приходится городить огород с триггерами и видами, получая в итоге тот же NoSQL видом сбоку, но только кривой и уродливый.
Какими триггерами? Посититать количество в материализованной view это дело трех строк на SQL и все.
И все равно NoSQL не получится ибо от реляционности мы никуда не уходим, просто делаем денормализацию, автоматически поддерживаемую сервером.
А ты как будешь строить облако тегов в NoSQL (желательно на примере реальной БД), так чтобы это не мешало другим сценариям, которые я еще в первом посте указал?
C>Кстати, упомянутый тобой Lucene — это абсолютно типичный пример подхода NoSQL. Попробуй её реализовать с помощью индексированных видов?
А полнотекстовый индекс в СУБД, это тоже NoSQL?
Может вообще любой индекс это NoSQL? Он ведь фактически тоже денормализацию выполняет (когда есть Included columns).
Давай не будем алгоритмы полнотекстового индекса мешать с системой хранения. Я могу вообще индексирование и поиск отдать гуглу\bing, или другому движку который выполняет индексирование страниц, а не данных в БД.
G>>>>А тут NoSQL причем? Как это вообще с системами хранения связано? C>>>А ты подумай. G>>Не, давай ты рассказывай. Как real-time оповещения связаны с NoSQL\RDBMS? C>Очень просто. К примеру, клиенты, получающие оповещения, не могут обращаться к БД по получении сообщения. Иначе оно всё умирает. C>Надо как-то хранить в каком-то очень быстром/распределённом кэше то, что они должны получить.
Ниче не понял.
С оповещениями надо рассматривать архитектуру, начиная с UI, а мне это лениво. Меня тут доступ к данным интересует.
Здравствуйте, rm822, Вы писали:
R>насколько я понял нету никаких VS R>либо ты можешь решить задачу на традиционных БД и пользуешься ими R>либо не можешь и выбирать не приходится
Ну у меня тоже ощущение складывается такое. Хотя многие утверждают обратное, что NoSQL заруливает вообще везде. Вот и хочется на реальном примере посмотреть.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>1)NoSQL не поддерживает join, вместо каждого join надо писать индекс на сервере C>>>NoSQL бывает разный. Есть и с join'ами, просто они не являются основой, в отличие от РСУБД. G>>Ссылку? C>В том же CouchDB делаешь простые табличные виды данных, и джойнишь их в ad-hoc запросах. В MongoDB описываешь связи с помощью http://www.mongodb.org/display/DOCS/Database+References#DatabaseReferences-DBRef и джойнишь по ним.
Во-первых там про join-ы по ним не сказано, во вторых:
DBRef's have the advantage of allowing optional automatic client-side dereferencing with some drivers
Так что это lazy load по факту, что является антиджоином.
C>>>>>С многими полнотекстовыми алгоритмами фигня выходит. G>>>>Полнотекстовый поиск стоит совершенно сбоку от системы хранения. C>>>Ну-ну. G>>Ты с чем не согласен? G>>Я часто для полнотекстового поиска использую Lucene.net, храню при этом все в РБД. C>Вот Lucene — это и есть типичный пример NoSQL. Так как её функциональность в рамках обычной РСУБД нормально не реализуется.
lucene это индекс, а NoSQL это хранение данных и доступ к ним.
C>А NoSQL базы — это можно считать неким фреймворком для создания система типа Lucene.
NoSQL не существует
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, gandjustas, Вы писали:
g>> То есть почти для всех программ NoSQL не подходит, так?
AB>Почти для всех программ, нет необходимости даже в отношениях — достаточно key-value хранилища (классический пример Berkeley DB).
Ок, покажи как эффективно реализовать юзкейсы из первого поста на key-value хранилище.
g>> Я пользуюсь сайтом, с чего бы там такая база подошла? g>> Нарисуй упрощенно юзкейсы, посмотрим.
AB>Документы могут иметь различное количество аттрибутов, аттрибуты в свою очередь тоже и т.д. — т.е. как раз та самая нечеткая схема, о которой ты говорил выше. Юзкесы вытекают.
Это какие документы? в сервисе "мое дело" набор полей всех сущностей фиксирован.
Здравствуйте, gandjustas, Вы писали:
G>Ну у меня тоже ощущение складывается такое. Хотя многие утверждают обратное, что NoSQL заруливает вообще везде. Вот и хочется на реальном примере посмотреть.
NoSQL круче SQL на столько же насколько asm круче java.
Здравствуйте, cvetkov, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Ну у меня тоже ощущение складывается такое. Хотя многие утверждают обратное, что NoSQL заруливает вообще везде. Вот и хочется на реальном примере посмотреть.
C>NoSQL круче SQL на столько же насколько asm круче java.
В точку, правда на asm ничего серьезного сделать нельзя, кроме не переносимого и не нужного кода ))
Здравствуйте, gandjustas, Вы писали:
C>>А какие проблемы-то? То что решается стандартными join'ами ими и будет решаться. А для более тяжёлых задач — NoSQL. G>Количество более тяжелых задач очень мало и там видимо не в самом применении NoSQL преимущества, а в способе распределения БД. G>Которое еще и упирается в CAP theorem.
С CAP'ом как раз рулят NoSQL, часть из которых специально затачивается под eventual consistency и т.п.
C>>Не, ну ты смешной. Вот у тебя статья, у неё набор тэгов. Как ты их будешь хранить? Как ты будешь строить облака тэгов? G>Связь много-ко-многим таблицы статей и тегов, индескированное представление для тегов, считающее количество использований тега. G>Для постоения облака — получаем все теги с количеством если оно больше нуля и строим.
Тэг "Windows". Общее количество — 20000000 штук. Плоховато...
C>>Сразу могу сказать, что на RDBMS нет хорошего решения. Приходится городить огород с триггерами и видами, получая в итоге тот же NoSQL видом сбоку, но только кривой и уродливый. G>Какими триггерами? Посититать количество в материализованной view это дело трех строк на SQL и все.
Ну попробуй.
G>И все равно NoSQL не получится ибо от реляционности мы никуда не уходим, просто делаем денормализацию, автоматически поддерживаемую сервером. G>А ты как будешь строить облако тегов в NoSQL (желательно на примере реальной БД), так чтобы это не мешало другим сценариям, которые я еще в первом посте указал? http://cookbook.mongodb.org/patterns/count_tags/http://www.mongodb.org/display/DOCS/MapReduce
C>>Кстати, упомянутый тобой Lucene — это абсолютно типичный пример подхода NoSQL. Попробуй её реализовать с помощью индексированных видов? G> G>А полнотекстовый индекс в СУБД, это тоже NoSQL?
Да.
G>Может вообще любой индекс это NoSQL? Он ведь фактически тоже денормализацию выполняет (когда есть Included columns).
Нет. Обычные индексы просто ускоряют реляционные операции. Т.е. являются деталями реализации.
А вот полнотекстовые индексы уже не выражаются в терминах реляционной алгебры.
G>Давай не будем алгоритмы полнотекстового индекса мешать с системой хранения. Я могу вообще индексирование и поиск отдать гуглу\bing, или другому движку который выполняет индексирование страниц, а не данных в БД.
Да-да.
C>>Очень просто. К примеру, клиенты, получающие оповещения, не могут обращаться к БД по получении сообщения. Иначе оно всё умирает. C>>Надо как-то хранить в каком-то очень быстром/распределённом кэше то, что они должны получить. G>Ниче не понял. G>С оповещениями надо рассматривать архитектуру, начиная с UI, а мне это лениво. Меня тут доступ к данным интересует.
Ну так попробуй. Обнаружишь, что с доступом к данным появляются интересные вопросы.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>А какие проблемы-то? То что решается стандартными join'ами ими и будет решаться. А для более тяжёлых задач — NoSQL. G>>Количество более тяжелых задач очень мало и там видимо не в самом применении NoSQL преимущества, а в способе распределения БД. G>>Которое еще и упирается в CAP theorem. C>С CAP'ом как раз рулят NoSQL, часть из которых специально затачивается под eventual consistency и т.п.\
Меня не это интересует, больше интересует как на NoSQL будут выполняться базовые юзкейсы приложения.
При распределении данных все равно придется избавляться от джоинов.
C>>>Не, ну ты смешной. Вот у тебя статья, у неё набор тэгов. Как ты их будешь хранить? Как ты будешь строить облака тэгов? G>>Связь много-ко-многим таблицы статей и тегов, индескированное представление для тегов, считающее количество использований тега. G>>Для постоения облака — получаем все теги с количеством если оно больше нуля и строим. C>Тэг "Windows". Общее количество — 20000000 штук. Плоховато...
Приведи свой вариант.
C>>>Сразу могу сказать, что на RDBMS нет хорошего решения. Приходится городить огород с триггерами и видами, получая в итоге тот же NoSQL видом сбоку, но только кривой и уродливый. G>>Какими триггерами? Посититать количество в материализованной view это дело трех строк на SQL и все. C>Ну попробуй.
Я так уже делал.
G>>И все равно NoSQL не получится ибо от реляционности мы никуда не уходим, просто делаем денормализацию, автоматически поддерживаемую сервером. G>>А ты как будешь строить облако тегов в NoSQL (желательно на примере реальной БД), так чтобы это не мешало другим сценариям, которые я еще в первом посте указал? C>http://cookbook.mongodb.org/patterns/count_tags/
Десяток строк для подсчета количества, функцию пересчета надо вызывать явно(!), работать она будет дохрена времени, а результат "Тэг "Windows". Общее количество — 20000000 штук." (С)
C>>>Кстати, упомянутый тобой Lucene — это абсолютно типичный пример подхода NoSQL. Попробуй её реализовать с помощью индексированных видов? G>> G>>А полнотекстовый индекс в СУБД, это тоже NoSQL? C>Да.
G>>Может вообще любой индекс это NoSQL? Он ведь фактически тоже денормализацию выполняет (когда есть Included columns). C>Нет. Обычные индексы просто ускоряют реляционные операции. Т.е. являются деталями реализации.
Полнотекстовый индекс тоже ускоряет операции.
C>А вот полнотекстовые индексы уже не выражаются в терминах реляционной алгебры.
Счегобы?
CONTAINS — обычный предикат, FREETEXTTABLE — обычная функция, возвращающая вполне реляционный resultset. Остальное детали реализации.
Если FTS не был реляционным, то его бы тупо нельзя было использовать в SQL.
C>>>Очень просто. К примеру, клиенты, получающие оповещения, не могут обращаться к БД по получении сообщения. Иначе оно всё умирает. C>>>Надо как-то хранить в каком-то очень быстром/распределённом кэше то, что они должны получить. G>>Ниче не понял. G>>С оповещениями надо рассматривать архитектуру, начиная с UI, а мне это лениво. Меня тут доступ к данным интересует. C>Ну так попробуй. Обнаружишь, что с доступом к данным появляются интересные вопросы.
Я же говорю — лениво.
Лучше ты сам опиши структуры на любой NoSQL базе для stackoverflow.
Здравствуйте, gandjustas, Вы писали:
C>>С CAP'ом как раз рулят NoSQL, часть из которых специально затачивается под eventual consistency и т.п.\ G>Меня не это интересует, больше интересует как на NoSQL будут выполняться базовые юзкейсы приложения. G>При распределении данных все равно придется избавляться от джоинов.
Нормально будет. А какие проблемы-то? Каждую статью с комментариями представляем как документ и вперёд с песней.
G>>>Для постоения облака — получаем все теги с количеством если оно больше нуля и строим. C>>Тэг "Windows". Общее количество — 20000000 штук. Плоховато... G>Приведи свой вариант.
См. вариант с mapreduce.
C>>http://cookbook.mongodb.org/patterns/count_tags/ G>Десяток строк для подсчета количества, функцию пересчета надо вызывать явно(!), работать она будет дохрена времени, а результат "Тэг "Windows". Общее количество — 20000000 штук." (С)
Учи матчасть. MapReduce ассоциативен, так что для этого запроса надо будет обрабатывать только новые данные. Вручную тоже его запускать необязательно.
G>>>Может вообще любой индекс это NoSQL? Он ведь фактически тоже денормализацию выполняет (когда есть Included columns). C>>Нет. Обычные индексы просто ускоряют реляционные операции. Т.е. являются деталями реализации. G>Полнотекстовый индекс тоже ускоряет операции.
Да. Но при этом является расширением реляционной модели.
C>>А вот полнотекстовые индексы уже не выражаются в терминах реляционной алгебры. G>Счегобы? G>CONTAINS — обычный предикат, FREETEXTTABLE — обычная функция, возвращающая вполне реляционный resultset. Остальное детали реализации.
Неа. Скажем, поиск фраз уже не особо реляционен.
G>Если FTS не был реляционным, то его бы тупо нельзя было использовать в SQL.
LOL!
G>Лучше ты сам опиши структуры на любой NoSQL базе для stackoverflow.
Так там нечего описывать. Всё тупо ложится на коллекцию документов.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>С CAP'ом как раз рулят NoSQL, часть из которых специально затачивается под eventual consistency и т.п.\ G>>Меня не это интересует, больше интересует как на NoSQL будут выполняться базовые юзкейсы приложения. G>>При распределении данных все равно придется избавляться от джоинов. C>Нормально будет. А какие проблемы-то? Каждую статью с комментариями представляем как документ и вперёд с песней.
Как в таком случае делать
1)Отображение всех комментов пользователя?
2)Отображение все вопросов и ответов пользователя?
3)Считать рейтинг пользователя (суммировать голоса)?
Подход "Каждую статью с комментариями представляем как документ" идет лесом.
C>>>http://cookbook.mongodb.org/patterns/count_tags/ G>>Десяток строк для подсчета количества, функцию пересчета надо вызывать явно(!), работать она будет дохрена времени, а результат "Тэг "Windows". Общее количество — 20000000 штук." (С) C>Учи матчасть. MapReduce ассоциативен, так что для этого запроса надо будет обрабатывать только новые данные. Вручную тоже его запускать необязательно.
В примере этого не увидел.
G>>>>Может вообще любой индекс это NoSQL? Он ведь фактически тоже денормализацию выполняет (когда есть Included columns). C>>>Нет. Обычные индексы просто ускоряют реляционные операции. Т.е. являются деталями реализации. G>>Полнотекстовый индекс тоже ускоряет операции. C>Да. Но при этом является расширением реляционной модели.
C>>>А вот полнотекстовые индексы уже не выражаются в терминах реляционной алгебры. G>>Счегобы? G>>CONTAINS — обычный предикат, FREETEXTTABLE — обычная функция, возвращающая вполне реляционный resultset. Остальное детали реализации. C>Неа. Скажем, поиск фраз уже не особо реляционен.
Если он не выражается с помощью функции, то да. Иначе — вполне реляционен. Остальное уже детали реализации.
G>>Если FTS не был реляционным, то его бы тупо нельзя было использовать в SQL. C>LOL!
G>>Лучше ты сам опиши структуры на любой NoSQL базе для stackoverflow. C>Так там нечего описывать. Всё тупо ложится на коллекцию документов.
Ну напиши структуру коллекции.
Здравствуйте, gandjustas, Вы писали:
G>Навеяно вот этим постом.
G>Есть всем известный сайт stackoverflow.com G>Возмем его упрощенную структуру: пользователи, вопросы, ответы, комменты, голоса, связи надеюсь понятны.
G>Надо спроектировать БД так чтобы она могла выдержать больше объемы, сравнимые с самим stackoverflow. Это около миллиона вопросов, 50 тыщ активных пользователей, 10 миллионов ответов и столько же комментов, 10 миллионов голосов.
пример проектирования NoSql (не stackoverflow.com, просто блог, но смысл понятен) от ayenda
G>Такая БД влезет примерно в 100 гб (в зависимости от длины вопросов и ответов). Один хороший сервак должен потянуть такую базу.
про один сервак ты сказал чтоб обойти проблему маштабирования?
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Навеяно вот этим постом.
G>>Есть всем известный сайт stackoverflow.com G>>Возмем его упрощенную структуру: пользователи, вопросы, ответы, комменты, голоса, связи надеюсь понятны.
G>>Надо спроектировать БД так чтобы она могла выдержать больше объемы, сравнимые с самим stackoverflow. Это около миллиона вопросов, 50 тыщ активных пользователей, 10 миллионов ответов и столько же комментов, 10 миллионов голосов.
C>пример проектирования NoSql (не stackoverflow.com, просто блог, но смысл понятен) от ayenda
Эта схема начинает сыпаться когда надо делать выборки по пользователю.
Кстати как в условиях распределенности будут работать индексы, которые вынуждены обрабатывать данные на всех серверах?
G>>Такая БД влезет примерно в 100 гб (в зависимости от длины вопросов и ответов). Один хороший сервак должен потянуть такую базу. C>про один сервак ты сказал чтоб обойти проблему маштабирования?
Просто это реально типовая задача для одного сервера.
C>>пример проектирования NoSql (не stackoverflow.com, просто блог, но смысл понятен) от ayenda
G>Эта схема начинает сыпаться когда надо делать выборки по пользователю.
какие выборки?
G>Кстати как в условиях распределенности будут работать индексы, которые вынуждены обрабатывать данные на всех серверах?
map-reduce идеальная распределенность
в couchdb другая схема Local Data Is King G>>>Такая БД влезет примерно в 100 гб (в зависимости от длины вопросов и ответов). Один хороший сервак должен потянуть такую базу. C>>про один сервак ты сказал чтоб обойти проблему маштабирования? G>Просто это реально типовая задача для одного сервера.
ну так одна из причин перехода фасебуков, твиттера, bbc и прочих гигантов это маштабирование.
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>пример проектирования NoSql (не stackoverflow.com, просто блог, но смысл понятен) от ayenda
G>>Эта схема начинает сыпаться когда надо делать выборки по пользователю. C>какие выборки?
Сводка по пользователю: кол-во постов, комментов, его блоги... как минимум.
G>>>>Такая БД влезет примерно в 100 гб (в зависимости от длины вопросов и ответов). Один хороший сервак должен потянуть такую базу. C>>>про один сервак ты сказал чтоб обойти проблему маштабирования? G>>Просто это реально типовая задача для одного сервера. C>ну так одна из причин перехода фасебуков, твиттера, bbc и прочих гигантов это маштабирование.
Твиттеры и фейсбуки далеко не каждый день пишутся, меня интересуют именно "обычные" приложения.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, cadet354, Вы писали:
C>>Здравствуйте, gandjustas, Вы писали:
C>>>>пример проектирования NoSql (не stackoverflow.com, просто блог, но смысл понятен) от ayenda
G>>>Эта схема начинает сыпаться когда надо делать выборки по пользователю. C>>какие выборки? G>Сводка по пользователю: кол-во постов, комментов, его блоги... как минимум.
// псевдокод
from result in docs
group result by result.author into g
where result.author="ayende"
select new {author = g.Key, count = g.Sum(x=>x.count) }
G>>>>>Такая БД влезет примерно в 100 гб (в зависимости от длины вопросов и ответов). Один хороший сервак должен потянуть такую базу. C>>>>про один сервак ты сказал чтоб обойти проблему маштабирования? G>>>Просто это реально типовая задача для одного сервера. C>>ну так одна из причин перехода фасебуков, твиттера, bbc и прочих гигантов это маштабирование. G>Твиттеры и фейсбуки далеко не каждый день пишутся, меня интересуют именно "обычные" приложения.
сорри, это я пропустил, для обычных это может быть нужно в ракурсе схема-free
Здравствуйте, Cyberax, Вы писали:
C>Нет. Обычные индексы просто ускоряют реляционные операции. Т.е. являются деталями реализации. C>А вот полнотекстовые индексы уже не выражаются в терминах реляционной алгебры.
Это ты мощно задвинул... А полнотекстовый индекс не деталь реализации?!
А как обычные индексы выражаются в терминах реляционной алгебры?
Похоже тебя занесло на броневик в порыве священной борьбы за NoSql. =)))
Здравствуйте, Cyberax, Вы писали:
C>Так там нечего описывать. Всё тупо ложится на коллекцию документов.
Ну вот у Орена тупо не получилось, а то что получилось что-то очень похоже на SQL. За что боролись?
Здравствуйте, Cyberax, Вы писали:
C>NoSQL бывает разный. Есть и с join'ами, просто они не являются основой, в отличие от РСУБД.
Ага, там где мы из NoSql сделали классическую реляционную таблицу, то там ясен байт джойны появились. Это ты такой NoSql продвигаешь? Я тогда лучше по старинке...
Здравствуйте, cadet354, Вы писали:
C>сорри, это я пропустил, для обычных это может быть нужно в ракурсе схема-free
Для обычных такая схема-free — это зло, так как требования меняются чаще чем срок жизни приложения, а за это free приходится платить тем, что запросы нужно явно прописывать в БД. Реляционка в этом смысле гораздо менее капризна, благодаря чему и получила такое распространение.
Здравствуйте, Cyberax, Вы писали:
C>Не, ну ты смешной. Вот у тебя статья, у неё набор тэгов. Как ты их будешь хранить? Как ты будешь строить облака тэгов?
Это ты про невозможность выполнения запроса
select tagName, density from
(select tagID, count(*) as density from ArticleTags where articleId = @articleId group by tagID) tagDensity
join Tag on Tag.ID = tagDensity.tagID
Или про что?
G>>Не, давай ты рассказывай. Как real-time оповещения связаны с NoSQL\RDBMS? C>Очень просто. К примеру, клиенты, получающие оповещения, не могут обращаться к БД по получении сообщения. Иначе оно всё умирает.
А зачем им обращаться в БД?
C>Надо как-то хранить в каком-то очень быстром/распределённом кэше то, что они должны получить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
G>Навеяно вот этим постом.
G>Есть всем известный сайт stackoverflow.com G>Возмем его упрощенную структуру: пользователи, вопросы, ответы, комменты, голоса, связи надеюсь понятны.
Я вообще проблемы не понимаю. У такого сайта, совершенно очевидно, есть "Blob" часть. Это где собственно тексты. И есть relation-часть — это где, скажем, метаданные (рейтинги, теги, пользователи — кто с кем связан).
Есть запросы совершенно разной природы. Скажем, запрос "сколько каких тегов назначил пользователь Вася" — это одно. А запрос типа "в каких вопросах встречается слово java" — другое.
То, что я назвал метаданными — это, собственно, реляции. Они очень компактны. Articles(ArticleId, AuthorId). ArticleTags(ArticleId, TagId, TaggerId).
Возьмём, к примеру, ходовой современный сервер от HP. Что мы имеем в пределах $10000?
16GB RAM
900GB HDD (уже с учётом RAID 1+0)
2 четырёхядерных intel xeon E5640 (16 виртуальных CPU)
Вы что, серьёзно думаете, что его удастся сколько-нибудь напрячь жалкими 20000000 тегов "Windows"? Да это смешно.
Всю реляционную часть можно засунуть в него и не париться ещё несколько лет.
Ещё один такой — и FTS летает с запасом.
Блобы можно отдавать из других источников — поскольку у нас HTTP и AJAX, можно пораскидывать их по целому кластеру. Читают много, исправляют мало. Reverse Proxy — наш ответ слэшдот-эффекту.
Ловкие чуваки для повышения эффективности кэширования никогда не обновляют документы. Каждая правка статьи (вопроса, ответа — неважно) приводит к генерации нового уникального ID. Это гарантирует нам отсутствие проблем с синхронизацией кэшей.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
C>>Не, ну ты смешной. Вот у тебя статья, у неё набор тэгов. Как ты их будешь хранить? Как ты будешь строить облака тэгов? S>Это ты про невозможность выполнения запроса
Нет.
S>
S>select tagName, density from
S>(select tagID, count(*) as density from ArticleTags where articleId = @articleId group by tagID) tagDensity
S>join Tag on Tag.ID = tagDensity.tagID
S>
S>Или про что?
Проблема в том, что count(*) у тебя должен по всем статьям выполняться.
G>>>Не, давай ты рассказывай. Как real-time оповещения связаны с NoSQL\RDBMS? C>>Очень просто. К примеру, клиенты, получающие оповещения, не могут обращаться к БД по получении сообщения. Иначе оно всё умирает. S>А зачем им обращаться в БД?
Ну так основная функциональность будет в слое быстрого доступа.
Здравствуйте, IB, Вы писали:
C>>NoSQL бывает разный. Есть и с join'ами, просто они не являются основой, в отличие от РСУБД. IB>Ага, там где мы из NoSql сделали классическую реляционную таблицу, то там ясен байт джойны появились. Это ты такой NoSql продвигаешь? Я тогда лучше по старинке...
Кто-то предлагал ВСЁ им заменять?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Cyberax, Вы писали:
C>>Не, ну ты смешной. Вот у тебя статья, у неё набор тэгов. Как ты их будешь хранить? Как ты будешь строить облака тэгов? S>Это ты про невозможность выполнения запроса S>
S>select tagName, density from
S>(select tagID, count(*) as density from ArticleTags where articleId = @articleId group by tagID) tagDensity
S>join Tag on Tag.ID = tagDensity.tagID
S>
S>Или про что?
Такой запрос реально умрет на приличном количестве записей ArticleTags. Надо материализованные view использовать.
Здравствуйте, Cyberax, Вы писали:
C>Проблема в том, что count(*) у тебя должен по всем статьям выполняться.
Прекрасно решается материализованной view. Это гораздо эффективнее, чем триггеры.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
G>Такой запрос реально умрет на приличном количестве записей ArticleTags. Надо материализованные view использовать.
Прелесть View — в том, что их можно материализовать уже после запуска проекта.
Есть у меня подозрение, что с NoSQL так не выйдет: при росте нагрузки в какой-то момент тупо придётся переписать всё заново.
Ну и "приличное количество" — это сколько? У нас строка характерным размером в 16 байт без хидеров. Начиная со скольки записей это перестанет влезать в кэш?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Такой запрос реально умрет на приличном количестве записей ArticleTags. Надо материализованные view использовать. S>Прелесть View — в том, что их можно материализовать уже после запуска проекта.
Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
Здравствуйте, Lloyd, Вы писали:
L>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
Кстати, есть еще ведь такая вещь как Analysis Services. Честно говоря, мне самому не пришлось пока с ним работать, только присматриваюсь. Но если я правильно понимаю, он позволяет делать весьма хитрые агрегаты. И, упрощенно говоря, может служить для того же, для чего служат материализованные вьюхи, только возможностей гораздо больше (там ведь даже свой язык запросов есть — MDX).
Здравствуйте, sunshine, Вы писали:
L>>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
S>Кстати, есть еще ведь такая вещь как Analysis Services. Честно говоря, мне самому не пришлось пока с ним работать, только присматриваюсь. Но если я правильно понимаю, он позволяет делать весьма хитрые агрегаты. И, упрощенно говоря, может служить для того же, для чего служат материализованные вьюхи, только возможностей гораздо больше (там ведь даже свой язык запросов есть — MDX).
они разве поддержтвают автоматическое обновление при обновлении данных?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, sunshine, Вы писали:
L>>>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
S>>Кстати, есть еще ведь такая вещь как Analysis Services. Честно говоря, мне самому не пришлось пока с ним работать, только присматриваюсь. Но если я правильно понимаю, он позволяет делать весьма хитрые агрегаты. И, упрощенно говоря, может служить для того же, для чего служат материализованные вьюхи, только возможностей гораздо больше (там ведь даже свой язык запросов есть — MDX).
L>они разве поддержтвают автоматическое обновление при обновлении данных?
Вот, к сожалению, не знаю — интересно было бы узнать, кстати. Но вообще, по моим скудным познаниям, там можно создавать вьюхи, которые включают в себя данные из таблиц указанной БД (и, кстати, эти вьюхи могут также включать в себя и не реляционные данные, а из очень разных источников). И на основе этих вьюх строятся кубы. Так что, по идее, скорее всего автоматическое обновление там должно быть. Прошу тех кто с этим работал подтвердить или опровергнуть.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, cadet354, Вы писали:
C>>сорри, это я пропустил, для обычных это может быть нужно в ракурсе схема-free IB>Для обычных такая схема-free — это зло, так как требования меняются чаще чем срок жизни приложения, а за это free приходится платить тем, что запросы нужно явно прописывать в БД. Реляционка в этом смысле гораздо менее капризна, благодаря чему и получила такое распространение.
не понял, чтоб увидеть новое поле в базе надо все равно прописывать запрос, да и логику обработки его, и как то его обрабатывать, чем это будет отличаться от например RavenDB с его аля Linq?
Схема с добавлением полей, новых составных частей документа удобнее реализуется в СouchDb благодаря встроенному REST.
Здравствуйте, Sinclair, Вы писали:
C>>Проблема в том, что count(*) у тебя должен по всем статьям выполняться. S>Прекрасно решается материализованной view. Это гораздо эффективнее, чем триггеры.
А с какой скоростью он работать будет?
Здравствуйте, gandjustas, Вы писали:
g> AB>Почти для всех программ, нет необходимости даже в отношениях — достаточно key-value хранилища (классический пример Berkeley DB). g> Ок, покажи как эффективно реализовать юзкейсы из первого поста на key-value хранилище.
Отображение главной страницы и страниц второго уровня, форматтер подсветки кода, рейтинг и т.д. при более-менее серьезной нагрузке. Юзкейсы с выборками сами по себе тривиальны и особого интереса не представляют, но постоянно их запрашивать из SQL слишком дорого даже если они лежат в query cache.
g> AB>Документы могут иметь различное количество аттрибутов, аттрибуты в свою очередь тоже и т.д. — т.е. как раз та самая нечеткая схема, о которой ты говорил выше. Юзкесы вытекают. g> Это какие документы? в сервисе "мое дело" набор полей всех сущностей фиксирован.
В силу своей интраверсии, граничащей с аутизмом, программист просто не в состоянии увидеть свою программу чужими глазами — глазами пользователей. Никто уже не хочет работать с программами с технологической парадигмой навороченного пользовательского интерфейса — кустарным творением программистов — когда для того, чтобы работать с системой, надо обязательно знать, как она устроена. Это типичное творение аутиста, которому гораздо важнее видеть, как работает его программа, чем разбираться в том, что она делает для пользователя.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Такой запрос реально умрет на приличном количестве записей ArticleTags. Надо материализованные view использовать. S>Прелесть View — в том, что их можно материализовать уже после запуска проекта. S>Есть у меня подозрение, что с NoSQL так не выйдет: при росте нагрузки в какой-то момент тупо придётся переписать всё заново.
У меня тоже, вот и хочется посмотреть как на приведенном примере будет выглядеть NoSQL база.
S>Ну и "приличное количество" — это сколько?
Ну если учесть около миллиона вопросов, каждый из них имеет в среднем 2 тега, будет два миллиона записей.
S>У нас строка характерным размером в 16 байт без хидеров. Начиная со скольки записей это перестанет влезать в кэш?
А каков размер кеша?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
G>>Но это далеко не то чем занимаются большая часть разработчиков.
L>А его разве выдвигают на роль инструмента для болшей части разработчиков?
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, gandjustas, Вы писали:
g>> AB>Почти для всех программ, нет необходимости даже в отношениях — достаточно key-value хранилища (классический пример Berkeley DB). g>> Ок, покажи как эффективно реализовать юзкейсы из первого поста на key-value хранилище.
AB>Отображение главной страницы и страниц второго уровня, форматтер подсветки кода, рейтинг и т.д. при более-менее серьезной нагрузке. Юзкейсы с выборками сами по себе тривиальны и особого интереса не представляют, но постоянно их запрашивать из SQL слишком дорого даже если они лежат в query cache.
Да меня эти рассуждения не интересуют. Меня интересует как будет построена БД, для обеспечения указанных кейсов на одном компе.
g>> AB>Документы могут иметь различное количество аттрибутов, аттрибуты в свою очередь тоже и т.д. — т.е. как раз та самая нечеткая схема, о которой ты говорил выше. Юзкесы вытекают. g>> Это какие документы? в сервисе "мое дело" набор полей всех сущностей фиксирован.
AB>
В силу своей интраверсии, граничащей с аутизмом, программист просто не в состоянии увидеть свою программу чужими глазами — глазами пользователей. Никто уже не хочет работать с программами с технологической парадигмой навороченного пользовательского интерфейса — кустарным творением программистов — когда для того, чтобы работать с системой, надо обязательно знать, как она устроена. Это типичное творение аутиста, которому гораздо важнее видеть, как работает его программа, чем разбираться в том, что она делает для пользователя.
AB>Расшифровка требуется?
Это ты о чем вообще? Я использую "мое дело", там все сущности с которыми я работаю имеют вполне определенную структуру.
Где так "документы"?
Здравствуйте, sunshine, Вы писали:
S>Здравствуйте, Lloyd, Вы писали:
L>>Здравствуйте, sunshine, Вы писали:
L>>>>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
S>>>Кстати, есть еще ведь такая вещь как Analysis Services. Честно говоря, мне самому не пришлось пока с ним работать, только присматриваюсь. Но если я правильно понимаю, он позволяет делать весьма хитрые агрегаты. И, упрощенно говоря, может служить для того же, для чего служат материализованные вьюхи, только возможностей гораздо больше (там ведь даже свой язык запросов есть — MDX).
L>>они разве поддержтвают автоматическое обновление при обновлении данных? S>Вот, к сожалению, не знаю — интересно было бы узнать, кстати. Но вообще, по моим скудным познаниям, там можно создавать вьюхи, которые включают в себя данные из таблиц указанной БД (и, кстати, эти вьюхи могут также включать в себя и не реляционные данные, а из очень разных источников). И на основе этих вьюх строятся кубы. Так что, по идее, скорее всего автоматическое обновление там должно быть. Прошу тех кто с этим работал подтвердить или опровергнуть.
Есть режим работы ROLAP, по скорости примерно как использование запросов к хранилищу. Еще есть MOLAP с proactive caching, который позволяет некоторое время выдавать адекватные результаты без процессинга.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sinclair, Вы писали:
C>>>Проблема в том, что count(*) у тебя должен по всем статьям выполняться. S>>Прекрасно решается материализованной view. Это гораздо эффективнее, чем триггеры. C>А с какой скоростью он работать будет?
Выборка будет работать как из обычной табицы, обновление материализованной view дает малый оверхед. Я прогонял тесты на вставку миллиона записей, которые суммировались в indexed view. Получилось около 12%, видимо зависит еще от размера записей.
Здравствуйте, gandjustas, Вы писали: S>>Есть у меня подозрение, что с NoSQL так не выйдет: при росте нагрузки в какой-то момент тупо придётся переписать всё заново. G>У меня тоже, вот и хочется посмотреть как на приведенном примере будет выглядеть NoSQL база.
Боюсь, не дождёмся.
S>>У нас строка характерным размером в 16 байт без хидеров. Начиная со скольки записей это перестанет влезать в кэш? G>А каков размер кеша?
Ну, например, 1 GB.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
G>Ну у меня тоже ощущение складывается такое. Хотя многие утверждают обратное, что NoSQL заруливает вообще везде.
и ты поверил?
какие-то там опенсорсники за 1-2года взяли и сделали то, на что у мс и оракла ушло 10 лет, и не просто сделали а еще и превзошли по всем параметрам
самому-то не смешно?
Здравствуйте, rm822, Вы писали:
G>>Ну у меня тоже ощущение складывается такое. Хотя многие утверждают обратное, что NoSQL заруливает вообще везде. R>и ты поверил? R>какие-то там опенсорсники за 1-2года взяли и сделали то, на что у мс и оракла ушло 10 лет, и не просто сделали а еще и превзошли по всем параметрам R>самому-то не смешно?
Ну если так судить, то смешно. С другой стороны отказ в NoSQL от некоторых фич может(теоретически) некоторые параметры вытянуть выше, чем у РБД.
Кроме того по интернету уже гуляют sucess stories применения NoSQL.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Cyberax, Вы писали: C>>А с какой скоростью он работать будет? S>Со скоростью мысли.
Медленно слишком.
Здравствуйте, rm822, Вы писали:
G>>Ну у меня тоже ощущение складывается такое. Хотя многие утверждают обратное, что NoSQL заруливает вообще везде. R>и ты поверил? R>какие-то там опенсорсники за 1-2года взяли и сделали то, на что у мс и оракла ушло 10 лет, и не просто сделали а еще и превзошли по всем параметрам R>самому-то не смешно?
Здравствуйте, gandjustas, Вы писали:
G>Ну у меня тоже ощущение складывается такое. Хотя многие утверждают обратное, что NoSQL заруливает вообще везде. Вот и хочется на реальном примере посмотреть.
Кто ж такое утверждает.
Здравствуйте, _d_m_, Вы писали:
___>Оракл гораааздо старшее MS SQL-я.
Ну, не гораздо, лет на 7 всего, если субэйс считать.
Oracle это примерно 79 год, Sybase — 86. А вот DB2, если считать System-R, может поспорить с Ораклом за старшинство... Точнее как, Oracle — это первая коммерческая RDBMS, но работы над System-R в IBM велись еще с начала семидесятых.
Так что основная промашка не про Оракл-MS, а про десять лет — в реальности там не меньше тридцати пяти. =))
Здравствуйте, Cyberax, Вы писали:
C>>>А с какой скоростью он работать будет? S>>Со скоростью мысли. C>Медленно слишком.
Это смотря кто как думает.
Просто если мы говорим об облаке размером, скажем, в 15000 тегов (с любым количеством собсно инстансов), то весь индексированный view влезет в пару экстентов. Так что при чтении из него I/O будет практически незаметным. И всё это — декларативно и бесплатно, безо всяких триггеров.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
IB>Так что основная промашка не про Оракл-MS, а про десять лет — в реальности там не меньше тридцати пяти. =))
я имел ввиду что алгоритмы на которых построены современные бд были более-менее известны где-то с 90х, и на их воплощение в полноценных продуктах ушло примерно 10 лет.
в конце концов современные девелоперы не будут повторять все ошибки древности
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Ну у меня тоже ощущение складывается такое. Хотя многие утверждают обратное, что NoSQL заруливает вообще везде. Вот и хочется на реальном примере посмотреть. C>Кто ж такое утверждает. http://www.rsdn.ru/forum/db/3954576.aspx
Да и ты любишь впихнуть NoSQL в любое место.
C>Реальные применения вполне есть. В том числе и на знаменитом LHC: http://nosql.mypopescu.com/post/1024337327/couchdb-users-the-large-hadron-collider , который до этого и так уже создал самую большую (на тот момент) базу данных в мире.
Так в том и дело, что меня не интересует "самая большая база в мире", меня интересуют обычные базы, которые создаются обычными программистами для обычных проектов.
Ну есть неадекватные товарищи.
G>Да и ты любишь впихнуть NoSQL в любое место.
Неа. Я прекрасно понимаю его [не]применимость.
C>>Реальные применения вполне есть. В том числе и на знаменитом LHC: http://nosql.mypopescu.com/post/1024337327/couchdb-users-the-large-hadron-collider , который до этого и так уже создал самую большую (на тот момент) базу данных в мире. G>Так в том и дело, что меня не интересует "самая большая база в мире", меня интересуют обычные базы, которые создаются обычными программистами для обычных проектов.
Я приводил примеры — обработка неструктурированных текстов. Это сейчас, пожалуй, одна из основных областей его применения. Ещё data mining с поиском корреляций.
Здравствуйте, Sinclair, Вы писали:
C>>Медленно слишком. S>Это смотря кто как думает. S>Просто если мы говорим об облаке размером, скажем, в 15000 тегов (с любым количеством собсно инстансов), то весь индексированный view влезет в пару экстентов. Так что при чтении из него I/O будет практически незаметным. И всё это — декларативно и бесплатно, безо всяких триггеров.
Ок. Как выглядеть запрос будет "взять все статьи с тегам 'windows%', 'api' и 'helloworld', отсортировав по популярности"?
Здравствуйте, Cyberax, Вы писали:
C>>>Реальные применения вполне есть. В том числе и на знаменитом LHC: http://nosql.mypopescu.com/post/1024337327/couchdb-users-the-large-hadron-collider , который до этого и так уже создал самую большую (на тот момент) базу данных в мире. G>>Так в том и дело, что меня не интересует "самая большая база в мире", меня интересуют обычные базы, которые создаются обычными программистами для обычных проектов. C>Я приводил примеры — обработка неструктурированных текстов. Это сейчас, пожалуй, одна из основных областей его применения. Ещё data mining с поиском корреляций.
Ты снова путаешь хранение и обработку. Обработка текстов никак не зависит от того где они хранятся.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sinclair, Вы писали:
C>>>Медленно слишком. S>>Это смотря кто как думает. S>>Просто если мы говорим об облаке размером, скажем, в 15000 тегов (с любым количеством собсно инстансов), то весь индексированный view влезет в пару экстентов. Так что при чтении из него I/O будет практически незаметным. И всё это — декларативно и бесплатно, безо всяких триггеров. C>Ок. Как выглядеть запрос будет "взять все статьи с тегам 'windows%', 'api' и 'helloworld', отсортировав по популярности"?
Что есть популярность?
Кстати приведи пример сайта или приложения где такой запрос возможен.
Здравствуйте, gandjustas, Вы писали:
C>>Ок. Как выглядеть запрос будет "взять все статьи с тегам 'windows%', 'api' и 'helloworld', отсортировав по популярности"? G>Что есть популярность?
Скажем, число страничек с таким тегом.
G>Кстати приведи пример сайта или приложения где такой запрос возможен.
Любой сайт с тэгами. Ну или родной Гугл, конечно же.
Здравствуйте, gandjustas, Вы писали:
C>>Я приводил примеры — обработка неструктурированных текстов. Это сейчас, пожалуй, одна из основных областей его применения. Ещё data mining с поиском корреляций. G>Ты снова путаешь хранение и обработку. Обработка текстов никак не зависит от того где они хранятся.
Ещё как зависит. Если ты хранишь текст как блоб в БД, то ничерта нормального у тебя не получится. Особенно, если нужна инкрементальная обработка данных.
Опять же, вопросы с распределённостью и промежуточными данными появляются.
Здравствуйте, Cyberax, Вы писали: C>Ок. Как выглядеть запрос будет "взять все статьи с тегам 'windows%', 'api' и 'helloworld', отсортировав по популярности"?
Мы что, проверяем мои знания SQL? На всякий случай поясню, что поиск по like здесь будет по очень маленькой таблице, т.к. различных тегов мало, и что поиск будет идти по индексу.
Популярность, что бы она тут ни значила, будет браться из индексированного view. Опять же, индекс будет очень компактным, обеспечивая незначительный I/O.
Может, уже перейдём к ответам NoSQL?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Ок. Как выглядеть запрос будет "взять все статьи с тегам 'windows%', 'api' и 'helloworld', отсортировав по популярности"? G>>Что есть популярность? C>Скажем, число страничек с таким тегом.
Мда... есть у нас 1000 страниц с тегом api и одна с тегами api и helloworld. Как сортировать?
G>>Кстати приведи пример сайта или приложения где такой запрос возможен. C>Любой сайт с тэгами. Ну или родной Гугл, конечно же. C>http://stackoverflow.com/questions/tagged/windows+api+helloworld
И по какому параметру там сортировка?
Вариант stakoverflow с сортировкой по времени:
select a.* from Articles a
where a.Id in (
select at.ArticleId from ArticleTags at
join Tags t on t.Id = at.TagId
where t.Name in ('windows', 'api', 'helloworld')
)
order by a.Posted desc
А теперь твой вариант.
Кстати если вдруг окажется слишком медленным этот запрос, то я вполне могу его профайлером погонять, добавить индексы и хинты, на кряйняк переписать. В случае NoSQL базы придется схему менять.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Я приводил примеры — обработка неструктурированных текстов. Это сейчас, пожалуй, одна из основных областей его применения. Ещё data mining с поиском корреляций. G>>Ты снова путаешь хранение и обработку. Обработка текстов никак не зависит от того где они хранятся. C>Ещё как зависит. Если ты хранишь текст как блоб в БД, то ничерта нормального у тебя не получится. Особенно, если нужна инкрементальная обработка данных.
Почему? Что мне мешает использовать MS SQL Server 2008 и его Filestream?
C>Опять же, вопросы с распределённостью и промежуточными данными появляются.
До распределенности может не дойти вообще. При нормальной работе с СУБД она вполне успешно вытягивает 100 гб базы и сотни обращений в секунду.
Ты снова сваливаешься в рассмотрение крайних случаев. Большинство приложений не требуют распределенности вообще.
Здравствуйте, gandjustas, Вы писали:
G>>>Ты снова путаешь хранение и обработку. Обработка текстов никак не зависит от того где они хранятся. C>>Ещё как зависит. Если ты хранишь текст как блоб в БД, то ничерта нормального у тебя не получится. Особенно, если нужна инкрементальная обработка данных. G>Почему? Что мне мешает использовать MS SQL Server 2008 и его Filestream?
Потому, что значительной частью работы является ведение промежуточных данных и раскидывание работы между хостами. Да, это не чисто задача хранилища.
C>>Опять же, вопросы с распределённостью и промежуточными данными появляются. G>До распределенности может не дойти вообще. При нормальной работе с СУБД она вполне успешно вытягивает 100 гб базы и сотни обращений в секунду. G>Ты снова сваливаешься в рассмотрение крайних случаев. Большинство приложений не требуют распределенности вообще.
Обработчики текстов — требуют. Так как там индексы не помогают, и задача состоит в перелопачивании больших массивов данных. Никакие одинокие СУБД не помогут — у них скорости не хватит.
Здравствуйте, gandjustas, Вы писали:
C>>Скажем, число страничек с таким тегом. G>Мда... есть у нас 1000 страниц с тегом api и одна с тегами api и helloworld. Как сортировать?
Эвристикой. Скажем, по сумме встречаемости.
C>>http://stackoverflow.com/questions/tagged/windows+api+helloworld G>И по какому параметру там сортировка?
По релевантности.
G>Вариант stakoverflow с сортировкой по времени: G>
G>select a.* from Articles a
G>where a.Id in (
G> select at.ArticleId from ArticleTags at
G> join Tags t on t.Id = at.TagId
G> where t.Name in ('windows', 'api', 'helloworld')
G>)
G>order by a.Posted desc
G>
Неправильно, оно найдёт у тебя все статьи с windows, api и helloworld. Статей с windows во внутреннем select'е будет 2000000 штук, и оно всё умрёт. Опять же, не решён вопрос с сортировкой и релевантностью.
G>А теперь твой вариант.
Сегодня чуть позже.
G>Кстати если вдруг окажется слишком медленным этот запрос, то я вполне могу его профайлером погонять, добавить индексы и хинты, на кряйняк переписать. В случае NoSQL базы придется схему менять.
Индексы тут не помогут.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Cyberax, Вы писали: C>>Ок. Как выглядеть запрос будет "взять все статьи с тегам 'windows%', 'api' и 'helloworld', отсортировав по популярности"? S>Мы что, проверяем мои знания SQL? На всякий случай поясню, что поиск по like здесь будет по очень маленькой таблице, т.к. различных тегов мало, и что поиск будет идти по индексу.
Это пофиг. Проблема в том, что при поиске статей по тэгам индексы не сильно помогают.
S>Популярность, что бы она тут ни значила, будет браться из индексированного view. Опять же, индекс будет очень компактным, обеспечивая незначительный I/O. S>Может, уже перейдём к ответам NoSQL?
Не, лень писать.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>>>Ты снова путаешь хранение и обработку. Обработка текстов никак не зависит от того где они хранятся. C>>>Ещё как зависит. Если ты хранишь текст как блоб в БД, то ничерта нормального у тебя не получится. Особенно, если нужна инкрементальная обработка данных. G>>Почему? Что мне мешает использовать MS SQL Server 2008 и его Filestream? C>Потому, что значительной частью работы является ведение промежуточных данных и раскидывание работы между хостами. Да, это не чисто задача хранилища.
Более того, это вообще не задача хранилища.
C>>>Опять же, вопросы с распределённостью и промежуточными данными появляются. G>>До распределенности может не дойти вообще. При нормальной работе с СУБД она вполне успешно вытягивает 100 гб базы и сотни обращений в секунду. G>>Ты снова сваливаешься в рассмотрение крайних случаев. Большинство приложений не требуют распределенности вообще. C>Обработчики текстов — требуют. Так как там индексы не помогают, и задача состоит в перелопачивании больших массивов данных. Никакие одинокие СУБД не помогут — у них скорости не хватит.
Ты уже надоел с большими массивами. Неинтересны мне большие массивы и обработчики текстов, я за свою практику вообще не видел таких задач. Этим занимаются поисковики, типа гугла, яндекса итп. Обычные приложения вполне могут использовать готовые движки индексации на объемах в пару сотен гигов.
Никто не мешает сделать распределенное индексирование этих данных, но совершенно пофиг где они хранятся.
Ты кстати так и не привел структуру для stackoverflow.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Скажем, число страничек с таким тегом. G>>Мда... есть у нас 1000 страниц с тегом api и одна с тегами api и helloworld. Как сортировать? C>Эвристикой. Скажем, по сумме встречаемости.
Не понял...
Вот тебе конкретный пример выше привел, в каком порядке в нем выдавать?
C>>>http://stackoverflow.com/questions/tagged/windows+api+helloworld G>>И по какому параметру там сортировка? C>По релевантности.
Не-а, тупо по дате Там вообще нет релевантности, ищется полное совпадение тегов.
G>>Вариант stakoverflow с сортировкой по времени: G>>
G>>select a.* from Articles a
G>>where a.Id in (
G>> select at.ArticleId from ArticleTags at
G>> join Tags t on t.Id = at.TagId
G>> where t.Name in ('windows', 'api', 'helloworld')
G>>)
G>>order by a.Posted desc
G>>
C>Неправильно, оно найдёт у тебя все статьи с windows, api и helloworld.
А надо чтобы все вместе было?
Это делается так: триггером на добавление\удаление ArticleTags клеим теги в строку через пробел, а потом через Contains (FTS) ищем.
Запрос будет еще проще
select a.* from Articles
where contains(...)
C>Статей с windows во внутреннем select'е будет 2000000 штук, и оно всё умрёт.
Если их во внутреннем цикле будет 2000000 штук, то и в выдаче их будет столько. И умрет само приложение, обрабатывая данные.
C>Опять же, не решён вопрос с сортировкой и релевантностью.
Ну да, ты еще не придумал определение релевантности в данном случае
G>>А теперь твой вариант. C>Сегодня чуть позже.
G>>Кстати если вдруг окажется слишком медленным этот запрос, то я вполне могу его профайлером погонять, добавить индексы и хинты, на кряйняк переписать. В случае NoSQL базы придется схему менять. C>Индексы тут не помогут.
Тебе — нет, мне — да.
Здравствуйте, gandjustas, Вы писали:
C>>>>Скажем, число страничек с таким тегом. G>>>Мда... есть у нас 1000 страниц с тегом api и одна с тегами api и helloworld. Как сортировать? C>>Эвристикой. Скажем, по сумме встречаемости. G>Не понял... G>Вот тебе конкретный пример выше привел, в каком порядке в нем выдавать?
Скажем, для каждой страницы по каждому тэгу оцениваем популярность, а потом ищем по сумме популярности.
C>>Неправильно, оно найдёт у тебя все статьи с windows, api и helloworld. G>А надо чтобы все вместе было?
Да, с учётом релевантности.
G>Это делается так: триггером на добавление\удаление ArticleTags клеим теги в строку через пробел, а потом через Contains (FTS) ищем.
Мимо. Тогда оно не найдёт "api, aaron, development, helloworld, windows". Нужен запрос "%api%helloworld%windows%", который в FTS работает что-то не быстро.
G>Запрос будет еще проще
А FTS на святом духе работает?
C>>Статей с windows во внутреннем select'е будет 2000000 штук, и оно всё умрёт. G>Если их во внутреннем цикле будет 2000000 штук, то и в выдаче их будет столько. И умрет само приложение, обрабатывая данные.
Ага. А вот статей с "windows, api, helloworld" — всего 1000 штук.
C>>Опять же, не решён вопрос с сортировкой и релевантностью. G>Ну да, ты еще не придумал определение релевантности в данном случае
А его и нет глобального, каждый придумывает свой.
C>>Индексы тут не помогут. G>Тебе — нет, мне — да.
Тебе тоже.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>>>Скажем, число страничек с таким тегом. G>>>>Мда... есть у нас 1000 страниц с тегом api и одна с тегами api и helloworld. Как сортировать? C>>>Эвристикой. Скажем, по сумме встречаемости. G>>Не понял... G>>Вот тебе конкретный пример выше привел, в каком порядке в нем выдавать? C>Скажем, для каждой страницы по каждому тэгу оцениваем популярность, а потом ищем по сумме популярности.
См выделенное.
G>>Это делается так: триггером на добавление\удаление ArticleTags клеим теги в строку через пробел, а потом через Contains (FTS) ищем. C>Мимо. Тогда оно не найдёт "api, aaron, development, helloworld, windows". Нужен запрос "%api%helloworld%windows%", который в FTS работает что-то не быстро.
Ты гонишь уже. См выделенное, вот тебе запрос. Практически один в один повторяет код реальной системы, на ста тысячах записей отрабатывает 0.3 сек на немощном компе (ноуте).
select a.* from Articles
where contains(a.Tags,' "api" AND "helloworld" and "windows" ')
G>>Запрос будет еще проще C>А FTS на святом духе работает?
На MS SQL Server он работает.
C>>>Статей с windows во внутреннем select'е будет 2000000 штук, и оно всё умрёт. G>>Если их во внутреннем цикле будет 2000000 штук, то и в выдаче их будет столько. И умрет само приложение, обрабатывая данные. C>Ага. А вот статей с "windows, api, helloworld" — всего 1000 штук.
Этот запрос дает другую выборку.
C>>>Опять же, не решён вопрос с сортировкой и релевантностью. G>>Ну да, ты еще не придумал определение релевантности в данном случае C>А его и нет глобального, каждый придумывает свой.
Мало кто придумывает, для выборки по тегам использую дефолтную сортировку, типа по убыванию даты добавления.
C>>>Индексы тут не помогут. G>>Тебе — нет, мне — да. C>Тебе тоже.
Мне уже помогают.
Здравствуйте, rm822, Вы писали:
R>я имел ввиду что алгоритмы на которых построены современные бд были более-менее известны где-то с 90х, и на их воплощение в полноценных продуктах ушло примерно 10 лет.
Ну как сказать. К моменту опубликования классической Concurrency Control and Recovery in Database systems в 87, все в ней описанное уже с успехом применялось в основных базах. Мохан получил премию тьюринга за свой ARIES, кажется в 92-м и к 95-му по этому принципу работало уже практически все что нуждалось в отказоустойчивости, включая NTFS.
Ребята из команды MSSQL рассказывали, что для добавления версионности в 2005-й MSSQL им понадобилось какое-то совсем смешное время, так как все алгоритмы были давно известны и изучены и нужно было только все аккуратно реализовать.
R>в конце концов современные девелоперы не будут повторять все ошибки древности
Да, на наш век хватит своих.. =))
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sinclair, Вы писали: C>Это пофиг. Проблема в том, что при поиске статей по тэгам индексы не сильно помогают.
Правда что ли? А мне вот кажется, что ровно приведённый запрос прекрасно ляжет на индексы. C>Не, лень писать.
А, ну это, в принципе, подтверждает подозрения топикстартера о том, что для реальных применений NoSQL требует слишком много писанины.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
C>>Здравствуйте, Sinclair, Вы писали: C>>Это пофиг. Проблема в том, что при поиске статей по тэгам индексы не сильно помогают. S>Правда что ли? А мне вот кажется, что ровно приведённый запрос прекрасно ляжет на индексы.
Не ляжет. Ситуация похожа на ситуацию с индексом по булевскому полю — он бесполезен, так как обычно не уменьшает число рядов, которые надо просканировать.
C>>Не, лень писать. S>А, ну это, в принципе, подтверждает подозрения топикстартера о том, что для реальных применений NoSQL требует слишком много писанины.
Увы.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sinclair, Вы писали:
C>>>Здравствуйте, Sinclair, Вы писали: C>>>Это пофиг. Проблема в том, что при поиске статей по тэгам индексы не сильно помогают. S>>Правда что ли? А мне вот кажется, что ровно приведённый запрос прекрасно ляжет на индексы. C>Не ляжет.
Ну конкретнее, почему не ляжет?
C>Ситуация похожа на ситуацию с индексом по булевскому полю — он бесполезен, так как обычно не уменьшает число рядов, которые надо просканировать.
Гыгы... ты вообще в курсе как индексы работают и что они оптимизируют?
Здравствуйте, gandjustas, Вы писали:
G>Как в таком случае делать G>1)Отображение всех комментов пользователя? G>2)Отображение все вопросов и ответов пользователя?
Правильный ответ: "никак". Предполагается, что человек, который использует NoSQL хорошо знает, чего он хочет и как он этого хочет. Если вы этого не знаете, или знаете но не вы, то NoSQL вам не подходит.
G>3)Считать рейтинг пользователя (суммировать голоса)?
Рейтинг пользователя можно не считать, а хранить в документе 'user' инкрементируя/декрементируя по месту. Это если детали не важны. Если важны, храним для пользователя коллекцию "голосов" и суммируем map/reduce.
G>Подход "Каждую статью с комментариями представляем как документ" идет лесом.
Зависит от запросов. В реляционных базах мы знаем, что для любого запроса можно настроить индексов и выполнить его более или менее быстро. Для NoSQL это неверно.
Здравствуйте, gandjustas, Вы писали:
C>>>>Индексы тут не помогут. G>>>Тебе — нет, мне — да. C>>Тебе тоже. G>Мне уже помогают.
Даже без FTS
select a.Id, a.Title, a.Body, a.Posted from Articles a
join ArticleTags at1 on a.Id = at1.ArticleId
join ArticleTags at2 on a.Id = at2.ArticleId
join ArticleTags at3 on a.Id = at3.ArticleId
join Tags as t1 on at1.TagId = t1.Id
join Tags as t2 on at2.TagId = t2.Id
join Tags as t3 on at3.TagId = t3.Id
where t1.Name = 'windows' and t2.Name = 'api' and t3.Name = 'helloworld'
order by a.Posted desc
Индексы по ArticleTags, Tags.Name
В таблице Articles 100000 записей, Tags — 3000, в ArticleTags около 120000 равномерно распределены по разным тегам и статьям.
Работает за 60мсек на моем ноуте на MS SQL Express 2008.
Даже если предположить линейный рост времени работы от объема (хотя по факту он логарифмический или около того), то на объемах, примерно соответствующих stakoverflow, это будет 0,6сек на ноуте и в десятки, а то и сотни, раз меньше на нормальном серваке и взрослой БД.
Так что даже обычные индексы прекрасно помогают и на такой задаче. Главное уметь использовать.
Здравствуйте, gandjustas, Вы писали:
G>Такая БД влезет примерно в 100 гб (в зависимости от длины вопросов и ответов). Один хороший сервак должен потянуть такую базу.
Сколько стоит этот "хороший сервак"? Что будет, когда он перестянет тянуть? Сколько будет стоить изменение структуры базы в 100Гб под нагрузкой? Можно ли вместо одного "хорошего сервера" использовать три "нормальных" или десять "плохих"?
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Как в таком случае делать G>>1)Отображение всех комментов пользователя? G>>2)Отображение все вопросов и ответов пользователя?
M>Правильный ответ: "никак". Предполагается, что человек, который использует NoSQL хорошо знает, чего он хочет и как он этого хочет. Если вы этого не знаете, или знаете но не вы, то NoSQL вам не подходит.
Я не знаю, вот и спрашиваю.
G>>3)Считать рейтинг пользователя (суммировать голоса)?
M>Рейтинг пользователя можно не считать, а хранить в документе 'user' инкрементируя/декрементируя по месту. Это если детали не важны.
Конечно важны, читай первый пост, смотри http://stackoverflow.com. Нужно для пользователя показывать его голоса, и кто за него проголосовал.
M>Если важны, храним для пользователя коллекцию "голосов" и суммируем map/reduce.
И на каждое добавление голоса на нужно обновлять "пользователя" в хранилище?
И как в таком случае считать голоса для вопросов\ответов?
G>>Подход "Каждую статью с комментариями представляем как документ" идет лесом. M>Зависит от запросов. В реляционных базах мы знаем, что для любого запроса можно настроить индексов и выполнить его более или менее быстро. Для NoSQL это неверно.
Я в первом посте привел юзкейсы. Можешь свой вариант NoSQL хранилища привести для них.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sinclair, Вы писали:
C>>>Здравствуйте, Sinclair, Вы писали: C>>>Это пофиг. Проблема в том, что при поиске статей по тэгам индексы не сильно помогают. S>>Правда что ли? А мне вот кажется, что ровно приведённый запрос прекрасно ляжет на индексы. C>Не ляжет. Ситуация похожа на ситуацию с индексом по булевскому полю — он бесполезен, так как обычно не уменьшает число рядов, которые надо просканировать.
Продолжаю непонимать. Выборка ID тегов делается в один приём.
Теперь у нас есть эффективный способ выбрать все статьи, помеченные этими тегами.
Благодаря наличию индекса по популярности мы эффективно делаем select top 10.
Общий I/O получается достаточно незначительным.
Ну и, конечно же, главный вопрос — а как вы собрались догонять шустродействие SQL здесь при помощи NoSQL?
C>>>Не, лень писать. S>>А, ну это, в принципе, подтверждает подозрения топикстартера о том, что для реальных применений NoSQL требует слишком много писанины. C>Увы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Такая БД влезет примерно в 100 гб (в зависимости от длины вопросов и ответов). Один хороший сервак должен потянуть такую базу.
M>Сколько стоит этот "хороший сервак"?
думаю 33-5 килобаксов.
M>Что будет, когда он перестянет тянуть?
Когда перестанет, тогда и думать.
M>Сколько будет стоить изменение структуры базы в 100Гб под нагрузкой?
Можно отключить на время. stackoverflow вполне допускает прости по часу.
M>Можно ли вместо одного "хорошего сервера" использовать три "нормальных" или десять "плохих"?
Незачем, тупо дешевле выходит один хороший сервак купить.
Здравствуйте, Sinclair, Вы писали:
C>>Не ляжет. Ситуация похожа на ситуацию с индексом по булевскому полю — он бесполезен, так как обычно не уменьшает число рядов, которые надо просканировать. S>Продолжаю непонимать. Выборка ID тегов делается в один приём.
Блин, да не в ID дело.
S>Теперь у нас есть эффективный способ выбрать все статьи, помеченные этими тегами.
Нету. У тебя есть не особо эффективный способ (так как результатов очень много) выбрать все статьи с данным тэгом. А вот хорошего способа заджойнить результаты выборки по нескольким тэгам уже нет.
S>Ну и, конечно же, главный вопрос — а как вы собрались догонять шустродействие SQL здесь при помощи NoSQL?
Key-value хранилище + индексный lookup по наименее частовстречающемуся тэгу/тэгам + распределённое сканирование остальных рядов. В теории оно возможно и на реляционной БД, но что-то я пока не слышал, чтобы кто-то кроме Oracle'овского RAC'а умел делать распределённые выборки.
Здравствуйте, gandjustas, Вы писали: G>Так что даже обычные индексы прекрасно помогают и на такой задаче. Главное уметь использовать.
Ты не переживай. Всегда можно подобрать определение релевантности так, чтобы по нему нельзя было построить indexed view в силу ограничений MS SQL. ("пропорционально квадрату релевантности" ) Нужно ли будет такое определение релевантности — вопрос другой.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Lloyd, Вы писали:
L>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
К счастью, для большинства остального достаточно индексировать то, что в коробке. К примеру, Average легко получить из индексированных Count и Sum. За остальным можно обратиться к университетскому курсу мат.статистики.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
C>>Ещё как зависит. Если ты хранишь текст как блоб в БД, то ничерта нормального у тебя не получится. Особенно, если нужна инкрементальная обработка данных. G>Почему? Что мне мешает использовать MS SQL Server 2008 и его Filestream?
Э, не. Тут вопрос не в том, "что мешает", а в том, "зачем".
Вся сила реляционок — в ad-hoc запросах, где важны отношения. Для хранения неструктурированных или слабоструктурированных данных никаких преимуществ реляционка не даст. Тем более, если задача не включает в себя OLTP.
Но вот проекты типа stackoverflow практически полностью построены на перекрёстных ссылках, в которых как раз реляционки традиционно сильны. Порвать их на этом поле будет крайне сложно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Miroff, Вы писали:
G>>Такая БД влезет примерно в 100 гб (в зависимости от длины вопросов и ответов). Один хороший сервак должен потянуть такую базу.
M>Сколько стоит этот "хороший сервак"? Что будет, когда он перестянет тянуть? Сколько будет стоить изменение структуры базы в 100Гб под нагрузкой? Можно ли вместо одного "хорошего сервера" использовать три "нормальных" или десять "плохих"?
Я тут рядом приводил пример хорошего сервака. 100гб влезет и в плохонький, стоимостью в пределах $3000.
Когда перестанет тянуть тот, что за $3000, можно заапгрейдить его в тот, который $5000. Потом — в тот, который за $8000. К моменту, когда сервак за $12000 перестанет устраивать, выйдет новая аппаратная платформа.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
L>>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ... S>К счастью, для большинства остального достаточно индексировать то, что в коробке. К примеру, Average легко получить из индексированных Count и Sum.
А min к примеру мы из чего получим?
S>За остальным можно обратиться к университетскому курсу мат.статистики.
Это ты круто вывернулся с примером-то. Прям может сложиться впечатление, что любой агрегат может быть выражен через то, есть в наличии. А тот, кто усомнился — тот лох и недоучка, пусть читает книжки.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sinclair, Вы писали:
C>>>Не ляжет. Ситуация похожа на ситуацию с индексом по булевскому полю — он бесполезен, так как обычно не уменьшает число рядов, которые надо просканировать. S>>Продолжаю непонимать. Выборка ID тегов делается в один приём. C>Блин, да не в ID дело.
Именно в ID. Выборка по ключу всегда делается максимально эффективно. Основная проблема в получении списка ключей для выборки.
S>>Теперь у нас есть эффективный способ выбрать все статьи, помеченные этими тегами. C>Нету. У тебя есть не особо эффективный способ (так как результатов очень много) выбрать все статьи с данным тэгом. А вот хорошего способа заджойнить результаты выборки по нескольким тэгам уже нет.
Неправда, см мой пост про индексы и FTS.
S>>Ну и, конечно же, главный вопрос — а как вы собрались догонять шустродействие SQL здесь при помощи NoSQL? C>Key-value хранилище + индексный lookup по наименее частовстречающемуся тэгу/тэгам + распределённое сканирование остальных рядов. В теории оно возможно и на реляционной БД, но что-то я пока не слышал, чтобы кто-то кроме Oracle'овского RAC'а умел делать распределённые выборки.
Вот с этого места поподробнее. Какая структура будет у хранимых ключей и значений чтобы эффективно обеспечивались другие кейсы, кроме указанной выборки по совокупности тегов?
Кстати стоит учесть что выборка по совокупности тегов — далеко не самый частый кейс. Более того, на примере stackoverflow, в интерфейсе вообще нет возможности получить такую выборки, только ручками набивать в url.
Ты лучше расскажи как ты будешь реализовывать на Key-value то что я в первом посте написал.
Здравствуйте, Sinclair, Вы писали:
C>>>Ещё как зависит. Если ты хранишь текст как блоб в БД, то ничерта нормального у тебя не получится. Особенно, если нужна инкрементальная обработка данных. G>>Почему? Что мне мешает использовать MS SQL Server 2008 и его Filestream? S>Э, не. Тут вопрос не в том, "что мешает", а в том, "зачем". S>Вся сила реляционок — в ad-hoc запросах, где важны отношения. Для хранения неструктурированных или слабоструктурированных данных никаких преимуществ реляционка не даст. Тем более, если задача не включает в себя OLTP.
Ну какбы именно это и решается фичами типа filestream и xml, чтобы можно было использовать РБД для работы с нереляционными данными. Когда все в одном месте — управлять проще.
S>Но вот проекты типа stackoverflow практически полностью построены на перекрёстных ссылках, в которых как раз реляционки традиционно сильны. Порвать их на этом поле будет крайне сложно.
Да нету там засилия "перекрестных ссылок", очень типовой веб-два-нольный сайт.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Sinclair, Вы писали:
L>>>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ... S>>К счастью, для большинства остального достаточно индексировать то, что в коробке. К примеру, Average легко получить из индексированных Count и Sum.
L>А min к примеру мы из чего получим?
Для всей таблицы — из индекса по полю. В остальных случаях — ручками в триггерах агрегировать.
S>>Теперь у нас есть эффективный способ выбрать все статьи, помеченные этими тегами. C>Нету. У тебя есть не особо эффективный способ (так как результатов очень много) выбрать все статьи с данным тэгом. А вот хорошего способа заджойнить результаты выборки по нескольким тэгам уже нет.
Да ну? Есть у меня вполне себе прекрасный способ.
Всё зависит от селективности выборок по каждому из тегов.
S>>Ну и, конечно же, главный вопрос — а как вы собрались догонять шустродействие SQL здесь при помощи NoSQL? C>Key-value хранилище + индексный lookup по наименее частовстречающемуся тэгу/тэгам + распределённое сканирование остальных рядов. В теории оно возможно и на реляционной БД, но что-то я пока не слышал, чтобы кто-то кроме Oracle'овского RAC'а умел делать распределённые выборки.
Ага, то есть ключ к успеху — в лукапе по наиболее селективному предикату? Ну так он в RDBMS точно так же побежит.
"Распределённое сканирование" потребуется ой как не скоро — не при масштабах stackoverflow.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
S>>>К счастью, для большинства остального достаточно индексировать то, что в коробке. К примеру, Average легко получить из индексированных Count и Sum.
L>>А min к примеру мы из чего получим? G>Для всей таблицы — из индекса по полю.
Для всей таблицы не интересно. Интересно с группировкой.
G>В остальных случаях — ручками в триггерах агрегировать.
Собственно, что и требовалось доказать:
Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
Здравствуйте, Lloyd, Вы писали:
L>Для всей таблицы не интересно. Интересно с группировкой.
G>>В остальных случаях — ручками в триггерах агрегировать.
L>Собственно, что и требовалось доказать: L>
L>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
L>
Ну я соврал. Если есть индекс (ключи группировки, поле для вычисления min), то значение будет из него браться.
Здравствуйте, gandjustas, Вы писали:
G>>>В остальных случаях — ручками в триггерах агрегировать.
L>>Собственно, что и требовалось доказать: L>>
L>>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
L>>
G>Ну я соврал. Если есть индекс (ключи группировки, поле для вычисления min), то значение будет из него браться.
Давай, прочитай еще раз, что я написал. Уверен, с третей попытки получится. Ключевые слова я выделил.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
G>>>>В остальных случаях — ручками в триггерах агрегировать.
L>>>Собственно, что и требовалось доказать: L>>>
L>>>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
L>>>
G>>Ну я соврал. Если есть индекс (ключи группировки, поле для вычисления min), то значение будет из него браться.
L>Давай, прочитай еще раз, что я написал. Уверен, с третей попытки получится. Ключевые слова я выделил.
Интересно увидеть сценарий, где у материализованной вьюхи понадобится и сумма, и минимум\максимум.
Здравствуйте, gandjustas, Вы писали:
G>>>Ну я соврал. Если есть индекс (ключи группировки, поле для вычисления min), то значение будет из него браться.
L>>Давай, прочитай еще раз, что я написал. Уверен, с третей попытки получится. Ключевые слова я выделил.
G>Интересно увидеть сценарий, где у материализованной вьюхи понадобится и сумма, и минимум\максимум.
L>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
вы отстали от жизни
Aggregate functions perform a calculation on a set of values and return a single value. Traditionally, Microsoft SQL Server has supported only built-in aggregate functions, such as SUM or MAX, that operate on a set of input scalar values and generate a single aggregate value from that set. SQL Server integration with the Microsoft .NET Framework common language runtime (CLR) now allows developers to create custom aggregate functions in managed code, and to make these functions accessible to Transact-SQL or other managed code.
L>>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
R>вы отстали от жизни
R>
R>Aggregate functions perform a calculation on a set of values and return a single value. Traditionally, Microsoft SQL Server has supported only built-in aggregate functions, such as SUM or MAX, that operate on a set of input scalar values and generate a single aggregate value from that set. SQL Server integration with the Microsoft .NET Framework common language runtime (CLR) now allows developers to create custom aggregate functions in managed code, and to make these functions accessible to Transact-SQL or other managed code.
Здравствуйте, rm822, Вы писали:
R>вы отстали от жизни
R>
R>Aggregate functions perform a calculation on a set of values and return a single value. Traditionally, Microsoft SQL Server has supported only built-in aggregate functions, such as SUM or MAX, that operate on a set of input scalar values and generate a single aggregate value from that set. SQL Server integration with the Microsoft .NET Framework common language runtime (CLR) now allows developers to create custom aggregate functions in managed code, and to make these functions accessible to Transact-SQL or other managed code.
Напиши в microsoft, скажи им, что они тоже отстали от жизни и не знают фич своего же продукта:
Unfortunately, floating point hardware on different computers (even with the same processor architecture from the same manufacturer) does not always stay 100% the same from version to version of the processor. A firmware upgrade might mean that (a*b) on the new hardware is not equal to (a*b) on the old hardware, for some floating point values a and b. For example, the results might be very close, but differ in the least significant bit. Persisting the imprecise computed values before indexing them solves this detach/attach inconsistency problem since all expressions are evaluated on the same computer during database update and maintenance of indexes and indexed views.
* Common Language Runtime (CLR) types. A major new feature of SQL Server 2005 is support for user-defined types (UDTs) and user-defined functions based on the CLR. Indexed views can be defined on CLR UDT columns, or expressions derived from those columns, provided that the columns or expressions are deterministic, and precise, persisted, or both. CLR user-defined aggregates cannot be used in an indexed view.
Здравствуйте, Sinclair, Вы писали:
S>Я тут рядом приводил пример хорошего сервака. 100гб влезет и в плохонький, стоимостью в пределах $3000. S>Когда перестанет тянуть тот, что за $3000, можно заапгрейдить его в тот, который $5000. Потом — в тот, который за $8000. К моменту, когда сервак за $12000 перестанет устраивать, выйдет новая аппаратная платформа.
а почему в обсуждении вообще игнорируется такой параметр как fault tolerant, или если сервак >10k то он "вечный" пока не выйдет новая аппаратная платформа?
Здравствуйте, gandjustas, Вы писали:
M>>Можно ли вместо одного "хорошего сервера" использовать три "нормальных" или десять "плохих"? G>Незачем, тупо дешевле выходит один хороший сервак купить.
Учитывая что с увеличением стоимости производительность сервера увеличивается нелинейно, не уверен что это будет даже дешевле. Кроме того, единственный сервер БД это в любом случае потенциальная точка отказа.
Здравствуйте, cadet354, Вы писали:
S>>Когда перестанет тянуть тот, что за $3000, можно заапгрейдить его в тот, который $5000. Потом — в тот, который за $8000. К моменту, когда сервак за $12000 перестанет устраивать, выйдет новая аппаратная платформа. C>а почему в обсуждении вообще игнорируется такой параметр как fault tolerant, или если сервак >10k то он "вечный" пока не выйдет новая аппаратная платформа?
Потому что вопросы fault tolerance здесь не поднимались. На всякий случай намекну, что HighAvailability != LoadBalancing. Особенно для stateful компонентов, которыми являются базы данных.
Если хочется реального Fault Tolerance, то решения в мире RDBMS конечно же есть.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, cadet354, Вы писали:
S>>>Когда перестанет тянуть тот, что за $3000, можно заапгрейдить его в тот, который $5000. Потом — в тот, который за $8000. К моменту, когда сервак за $12000 перестанет устраивать, выйдет новая аппаратная платформа. C>>а почему в обсуждении вообще игнорируется такой параметр как fault tolerant, или если сервак >10k то он "вечный" пока не выйдет новая аппаратная платформа? S>Потому что вопросы fault tolerance здесь не поднимались. На всякий случай намекну, что HighAvailability != LoadBalancing. Особенно для stateful компонентов, которыми являются базы данных.
т.е. "обычным приложениям" fault tolerance не нужен, понятно что даже 98% простым распределением нагрузки не получишь (это суммарно около недели в год, думаю под обычные приложения вполне попадает), но это один из необходимых методов решения single point of failure S>Если хочется реального Fault Tolerance, то решения в мире RDBMS конечно же есть.
только стоят как самолет.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
M>>>Можно ли вместо одного "хорошего сервера" использовать три "нормальных" или десять "плохих"? G>>Незачем, тупо дешевле выходит один хороший сервак купить.
M>Учитывая что с увеличением стоимости производительность сервера увеличивается нелинейно, не уверен что это будет даже дешевле.
А ты производительность в чем считаешь? Во что упирается производительность СУБД?
M>Кроме того, единственный сервер БД это в любом случае потенциальная точка отказа.
И что? fault-tolerant для большинства систем не нужен. тот же stackoverflow допускает простои по часу раз в месяц.
Здравствуйте, cadet354, Вы писали:
S>>Если хочется реального Fault Tolerance, то решения в мире RDBMS конечно же есть. C>только стоят как самолет.
Счегобы? В MS SQL 2008 есть failover cluster, достаточно двух серверов с NLB и на проекте уровня stackoverflow можно получить заветные пять девяток.
По цене это выйдет как два сервака с базами данных.
Здравствуйте, gandjustas, Вы писали:
G>Счегобы? В MS SQL 2008 есть failover cluster, достаточно двух серверов с NLB и на проекте уровня stackoverflow можно получить заветные пять девяток.
как указал Sinclair HighAvailability != LoadBalancing, пять девяток это единицы минут простоя в год, не верю. G>По цене это выйдет как два сервака с базами данных.
а сколько будет стоить OS, там вроде нужен enteprise или datacenter, хотя это мелочи перед стоимостью самого MS SQL.
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Счегобы? В MS SQL 2008 есть failover cluster, достаточно двух серверов с NLB и на проекте уровня stackoverflow можно получить заветные пять девяток. C>как указал Sinclair HighAvailability != LoadBalancing,
NLB это название технологии в Windows Server, используется для failover clustering в БД.
C>пять девяток это единицы минут простоя в год, не верю.
Железо+БД это обеспечит, а вот приложение и окружающая среда — вряд ли, особенно в России.
G>>По цене это выйдет как два сервака с базами данных. C>а сколько будет стоить OS, там вроде нужен enteprise или datacenter, хотя это мелочи перед стоимостью самого MS SQL.
Ось — windows server standard, около 1000 баксов, СУБД в зависимости от модели лицензирования — от 2 до 10 килобаксов.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, cadet354, Вы писали:
C>>Здравствуйте, gandjustas, Вы писали:
G>>>Счегобы? В MS SQL 2008 есть failover cluster, достаточно двух серверов с NLB и на проекте уровня stackoverflow можно получить заветные пять девяток. C>>как указал Sinclair HighAvailability != LoadBalancing, G>NLB это название технологии в Windows Server, используется для failover clustering в БД.
Network Load Balancing =NLB (это еще один сервер нужен?)
C>>пять девяток это единицы минут простоя в год, не верю. G>Железо+БД это обеспечит, а вот приложение и окружающая среда — вряд ли, особенно в России.
G>>>По цене это выйдет как два сервака с базами данных. C>>а сколько будет стоить OS, там вроде нужен enteprise или datacenter, хотя это мелочи перед стоимостью самого MS SQL. G>Ось — windows server standard, около 1000 баксов, СУБД в зависимости от модели лицензирования — от 2 до 10 килобаксов.
это какая редакция ms sql, тут цены на Enterprise больше 20K на процессор тут пишут про требования к OS
The failover cluster feature is available in Windows Server 2008 Enterprise and Windows Server 2008 Datacenter. The feature is not available in Windows Web Server 2008 or Windows Server 2008 Standard.
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, cadet354, Вы писали:
C>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Счегобы? В MS SQL 2008 есть failover cluster, достаточно двух серверов с NLB и на проекте уровня stackoverflow можно получить заветные пять девяток. C>>>как указал Sinclair HighAvailability != LoadBalancing, G>>NLB это название технологии в Windows Server, используется для failover clustering в БД. C>Network Load Balancing =NLB (это еще один сервер нужен?)
Ага.
G>>Ось — windows server standard, около 1000 баксов, СУБД в зависимости от модели лицензирования — от 2 до 10 килобаксов. C>это какая редакция ms sql, C>тут цены на Enterprise больше 20K на процессор
Не надо такой покупать, для stackoverflow и standard хватит.
C>тут пишут про требования к OS
Это не то, см NLB.
Здравствуйте, gandjustas, Вы писали:
C>>Network Load Balancing =NLB (это еще один сервер нужен?) G>Ага.
показать новый single point of failure ?
G>>>Ось — windows server standard, около 1000 баксов, СУБД в зависимости от модели лицензирования — от 2 до 10 килобаксов. C>>это какая редакция ms sql, C>>тут цены на Enterprise больше 20K на процессор G>Не надо такой покупать, для stackoverflow и standard хватит.
тогда и indexed view пропадут
на самом деле как реплицировать данные, насколько хорошо будет работать master-master репликация ?
Здравствуйте, cadet354, Вы писали:
G>>>>Ось — windows server standard, около 1000 баксов, СУБД в зависимости от модели лицензирования — от 2 до 10 килобаксов. C>>>это какая редакция ms sql, C>>>тут цены на Enterprise больше 20K на процессор G>>Не надо такой покупать, для stackoverflow и standard хватит. C>тогда и indexed view пропадут
Никуда они не пропадут, даже в express все есть.
C>на самом деле как реплицировать данные, насколько хорошо будет работать master-master репликация ?
Не проверял, работало и все
Здравствуйте, gandjustas, Вы писали:
C>>тогда и indexed view пропадут G>Никуда они не пропадут, даже в express все есть.
врут значит тут?
C>>на самом деле как реплицировать данные, насколько хорошо будет работать master-master репликация ? G>Не проверял, работало и все
Здравствуйте, cadet354, Вы писали:
C>т.е. "обычным приложениям" fault tolerance не нужен, понятно что даже 98% простым распределением нагрузки не получишь (это суммарно около недели в год, думаю под обычные приложения вполне попадает), но это один из необходимых методов решения single point of failure
98% в год получится на одном сервере забесплатно — за неделю тебе привезут новую железку из магазина.
S>>Если хочется реального Fault Tolerance, то решения в мире RDBMS конечно же есть. C>только стоят как самолет.
Можно пример расчёта стоимости "самолёта" в студию?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, cadet354, Вы писали:
C>>т.е. "обычным приложениям" fault tolerance не нужен, понятно что даже 98% простым распределением нагрузки не получишь (это суммарно около недели в год, думаю под обычные приложения вполне попадает), но это один из необходимых методов решения single point of failure S>98% в год получится на одном сервере забесплатно — за неделю тебе привезут новую железку из магазина.
ага, а сервера у нас не перегружаются, хотя бы при установке update, новые версии не ставяться и т.д.
S>>>Если хочется реального Fault Tolerance, то решения в мире RDBMS конечно же есть. C>>только стоят как самолет. S>Можно пример расчёта стоимости "самолёта" в студию?
oracle rac порядка 20k на процессор
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>тогда и indexed view пропадут G>>Никуда они не пропадут, даже в express все есть. C>врут значит тут?
Для версий кроме enterprise и developer надо указывать hint в запросе чтобы не пересчитывать агрегаты.
Здравствуйте, cadet354, Вы писали:
S>>>>Если хочется реального Fault Tolerance, то решения в мире RDBMS конечно же есть. C>>>только стоят как самолет. S>>Можно пример расчёта стоимости "самолёта" в студию? C>oracle rac порядка 20k на процессор
Оракл покупают те кто может себе это позволить. Те кто не может даже не смотрят в его сторону.
Здравствуйте, cadet354, Вы писали:
C>ага, а сервера у нас не перегружаются, хотя бы при установке update, новые версии не ставяться и т.д.
Апдейты приезжают по вторым вторникам каждого месяца; рестарт занимает около десяти минут. Итого имеем 2 часа на всё.
Это предполагая, что рестарт нужен для всех апдейтов.
S>>>>Если хочется реального Fault Tolerance, то решения в мире RDBMS конечно же есть. C>>>только стоят как самолет. S>>Можно пример расчёта стоимости "самолёта" в студию? C>oracle rac порядка 20k на процессор
Опупеть. А в MS SQL почему-то Active/Passive кластер входит в обычную Standard редакцию, причём пассивному серверу лицензия не нужна.
Порыл — нашёл смешную картинку здесь. Похоже парням в Oracle просто деньги очень нужны.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
G>Навеяно вот этим постом.
G>Есть всем известный сайт stackoverflow.com G>Возмем его упрощенную структуру: пользователи, вопросы, ответы, комменты, голоса, связи надеюсь понятны.
G>Надо спроектировать БД так чтобы она могла выдержать больше объемы, сравнимые с самим stackoverflow. Это около миллиона вопросов, 50 тыщ активных пользователей, 10 миллионов ответов и столько же комментов, 10 миллионов голосов.
G>Функционал как на сайте — список последних вопросов, список популярных вопросов, список неотвеченных вопросов, вопрос с ответами и комментами с сортировкой по ответам (дата, количество голосов), статистика пользователя: что когда где написал, прокомментил, проголосовал. Ну и сами действия: написание\правка вопроса, ответа, коммента, голосование.
G>Полнотекстовый поиск отдаем внешнему компоненту, типа lucene или google\bing.
G>Подход RDB очевиден: G>1)создать нормализованные таблицы G>2)сделать индексированные view, считающие количество голосов по ответам, комментам, пользователям G>3)Сделать индексированное view для подсчета количества ответов и голосов по вопросам G>4)В случае невозможности сделать view — пересчитывать в триггерах G>5)Понаделать индексов чтобы не было ни одного scan для выборки
G>Такая БД влезет примерно в 100 гб (в зависимости от длины вопросов и ответов). Один хороший сервак должен потянуть такую базу.
G>Что нам предложит NoSQL подход в данном случае?
Даст свободное время на реализацию бизнес логики, т.к. вы престанете заниматься фигней, закручивая гайки растущему организму.
В начале нужно делом заниматься. При этом еще не известно какие данные и структуры там будут. Это известно лишь когда проект закончен. Вот когда проект принесет вам миллиард долларов, купите себе остров, вот там тогда до старости можете переписывать на RDBMS, придумывать нормальные формы, индексы, вьюхи и тригеры.
Здравствуйте, Аноним, Вы писали:
G>>Что нам предложит NoSQL подход в данном случае?
А>Даст свободное время на реализацию бизнес логики, т.к. вы престанете заниматься фигней, закручивая гайки растущему организму.
Бред.
А>В начале нужно делом заниматься. При этом еще не известно какие данные и структуры там будут.
Вот я тебе уже написал какие данные будут. Вот займись делом, создай БД для них.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
S>>>>К счастью, для большинства остального достаточно индексировать то, что в коробке. К примеру, Average легко получить из индексированных Count и Sum.
L>>>А min к примеру мы из чего получим? G>>Для всей таблицы — из индекса по полю.
L>Для всей таблицы не интересно. Интересно с группировкой.
G>>В остальных случаях — ручками в триггерах агрегировать.
L>Собственно, что и требовалось доказать: L>
L>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
L>
И?
А теперь давай выйдем из области сферического коня в вакууме и ты нам покажешь, как этот "невероятно досадный недостаток" нам может помешать. Какие такие фендибоберные агрегаты нам необходимы вообще и в контексте топика в частности?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, cadet354, Вы писали:
C>>Здравствуйте, gandjustas, Вы писали:
C>>>>тогда и indexed view пропадут G>>>Никуда они не пропадут, даже в express все есть. C>>врут значит тут? G>Для версий кроме enterprise и developer надо указывать hint в запросе чтобы не пересчитывать агрегаты.
Правильно будет так: "чтобы движок СУБД не раворачивал представление в запросе".
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>тогда и indexed view пропадут G>>Никуда они не пропадут, даже в express все есть. C>врут значит тут?
Врут. И врут еще с 2000 версии. Работаем с индексными представлениями еще с 2000 версии. И работало в т.ч. на MSDE.
Здравствуйте, Аноним, Вы писали: А>Даст свободное время на реализацию бизнес логики, т.к. вы престанете заниматься фигней, закручивая гайки растущему организму. А>В начале нужно делом заниматься. При этом еще не известно какие данные и структуры там будут. Это известно лишь когда проект закончен. Вот когда проект принесет вам миллиард долларов, купите себе остров, вот там тогда до старости можете переписывать на RDBMS, придумывать нормальные формы, индексы, вьюхи и тригеры.
А по-моему всё строго наоборот. Там, где на RDBMS я могу накидать структуру нормализованной базы и взлететь, подкручивая индексы и денормализуя на лету по мере роста нагрузки, на NoSQL я буду вынужден заранее проектировать всю структуру с учётом будущей (пока ещё неизвестной) нагрузки.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Аноним, Вы писали:
А>Даст свободное время на реализацию бизнес логики, т.к. вы престанете заниматься фигней, закручивая гайки растущему организму.
Послушай, растущий арханизьм, куда у тебя гайки-то накручиваются?
А>В начале нужно делом заниматься. При этом еще не известно какие данные и структуры там будут. Это известно лишь когда проект закончен.
Б-ха-ха. Т.е. ты обычно садишься такой: "а дай-ка напишу что-нибудь низнамо что, а что за приложение получится фиг его знает, может Word, а может Excel, а может игра какая. Это будет известно лишь когда проект закончен".
Растущий арханизьм, ты витаминок больше кушай, чтобы мозгам тоже доставалось.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, cadet354, Вы писали:
C>>>Здравствуйте, gandjustas, Вы писали:
C>>>>>тогда и indexed view пропадут G>>>>Никуда они не пропадут, даже в express все есть. C>>>врут значит тут? G>>Для версий кроме enterprise и developer надо указывать hint в запросе чтобы не пересчитывать агрегаты.
___>Правильно будет так: "чтобы движок СУБД не раворачивал представление в запросе".
Здравствуйте, _d_m_, Вы писали:
L>>Собственно, что и требовалось доказать: L>>
L>>Кроме прелестей у материализованных вьюх есть и недостатки — например, агрегаты ограничены теми, что предоставляет SQL Server "ис каропки", в отличии от ...
L>>
___>И? ___>А теперь давай выйдем из области сферического коня в вакууме и ты нам покажешь, как этот "невероятно досадный недостаток" нам может помешать. Какие такие фендибоберные агрегаты нам необходимы вообще и в контексте топика в частности?
Пример я уже приводил, вполне обыденный, а комментарий относился не конкретно к тебе обсуждение, а вообще.
C>>ага, а сервера у нас не перегружаются, хотя бы при установке update, новые версии не ставяться и т.д. S>Апдейты приезжают по вторым вторникам каждого месяца; рестарт занимает около десяти минут. Итого имеем 2 часа на всё. S>Это предполагая, что рестарт нужен для всех апдейтов.
иногда установка update делает систему весьма мало отзывчивой. S>Опупеть. А в MS SQL почему-то Active/Passive кластер входит в обычную Standard редакцию, причём пассивному серверу лицензия не нужна. S>Порыл — нашёл смешную картинку здесь. Похоже парням в Oracle просто деньги очень нужны.
если в ms всё так хорошо с репликацией(master-slave я сам использую, давно пробывал на mysql делать master-master, больше не хочу),
то откуда столько стона, что sql маштабируется плохо, забывают добавить что плохо только в MySQL/Postgre ?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, _d_m_, Вы писали:
___>>А теперь давай выйдем из области сферического коня в вакууме и ты нам покажешь, как этот "невероятно досадный недостаток" нам может помешать. Какие такие фендибоберные агрегаты нам необходимы вообще и в контексте топика в частности?
L>Пример я уже приводил, вполне обыденный, а комментарий относился не конкретно к тебе обсуждение, а вообще.
Ну по min и всему аналогичному — здесь все понятно. При модификациях исходных таблиц представления, для функции min требуется пересчет всей группировки, куда относятся модифицируемые данные. Для sum и count же достаточно прибавить/вычесть из текущего значения группировки.
Если же не устраивает функционал инд.представлений, то здесь поможет своя таблица с аггрегированными значениями, плюс триггеры на исходные таблицы для модификаций оной.
Здравствуйте, _d_m_, Вы писали:
___>>>А теперь давай выйдем из области сферического коня в вакууме и ты нам покажешь, как этот "невероятно досадный недостаток" нам может помешать. Какие такие фендибоберные агрегаты нам необходимы вообще и в контексте топика в частности?
L>>Пример я уже приводил, вполне обыденный, а комментарий относился не конкретно к тебе обсуждение, а вообще.
___>Ну по min и всему аналогичному — здесь все понятно. При модификациях исходных таблиц представления, для функции min требуется пересчет всей группировки, куда относятся модифицируемые данные. Для sum и count же достаточно прибавить/вычесть из текущего значения группировки.
___>Если же не устраивает функционал инд.представлений, то здесь поможет своя таблица с аггрегированными значениями, плюс триггеры на исходные таблицы для модификаций оной.
Ну ты просто молодец. Я именно об этом и написал, что индексируемыми приедставлениями не все агрегаты разруливаются. Я же не писал, что rdbms — полное га*но по вышеуказанной причине, есть в них и другие способы решить озвученую проблему.
Здравствуйте, Lloyd, Вы писали:
L>Ну ты просто молодец.
Спасибо, я знаю
L>Я именно об этом и написал, что индексируемыми приедставлениями не все агрегаты разруливаются. Я же не писал, что rdbms — полное га*но по вышеуказанной причине, есть в них и другие способы решить озвученую проблему.
Да не верю я в серебряные пули. Все в конечном счете имеет цену — что RDBMS, что этосамоекакего использует те же диски, те же процессоры. И каким же волшебным образом этосамоекакего обойдет на виражах RDBMS? Ну только если этосамоекакего заточено исключительно под очень узкий и конкретный сценарий.
Здравствуйте, _d_m_, Вы писали:
___>И каким же волшебным образом этосамоекакего обойдет на виражах RDBMS?
Представь, что у тебя агрегат хранится в виде дерева. Листовые элементы соответствуют записям в БД. Не-листовые — промежуточные результаты агрегации.
В этом случае при изменениях в записях БД (листовые элементы) не нужно будет пересчитывать аргетат полностью просматривая все записи, а достаточно пересчитать толко агрегаты, в узлах, соединяющих измененные записи с корнем дерева.
На этом принципе и работает map-reduce в nosql-базах.
Здравствуйте, cadet354, Вы писали: C>то откуда столько стона, что sql маштабируется плохо, забывают добавить что плохо только в MySQL/Postgre ?
1. Где столько стона?
2. Мы опять путаем High Availability с Load Balancing? Или это внезапная смена темы?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, cadet354, Вы писали: C>>то откуда столько стона, что sql маштабируется плохо, забывают добавить что плохо только в MySQL/Postgre ? S>1. Где столько стона? например тут (на этот пост много кто ссылается, тот же Аенда) S>2. Мы опять путаем High Availability с Load Balancing? Или это внезапная смена темы?
нет, я про маштабирование,High Availability с Load Balancing этот от тебя появилось.
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, cadet354, Вы писали: C>>>то откуда столько стона, что sql маштабируется плохо, забывают добавить что плохо только в MySQL/Postgre ? S>>1. Где столько стона? C>например тут (на этот пост много кто ссылается, тот же Аенда)
Ну вы же понимаете что подавляющее большинство приложений таких проблем не увидит, а если увидит, то:
1)Использовать возможности partitioning, которые позволяют часть данных выключать из обработки, что увеличит возможности вертикального масштабирования
2)Сделать аппаратный load balancing с зеркалированием
3)Тупо отказаться нормализации там где возможно понадобится делать join_ы
4)Отказаться от server-side joins в некоторых случаях, а использовать джоины на клиенте для подстановки справочных данных
Только когда все возможности обычной СУБД исчерпаны (а это ох как нескоро случится) тогда необходимо заниматься перекладыванием работы в OLAP и key-value store\document db (для кеширования).
Хотя обычно этим начинают заниматься раньше, чтобы банально повысить отзывчивость и масштабируемость сервера (не БД, а сервера приложений), потому что запросы к БД все равно выполняются медленнее, чем аналогичная выборка из OLAP или кеша.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, Lloyd, Вы писали:
L>>Здравствуйте, _d_m_, Вы писали:
___>>>А теперь давай выйдем из области сферического коня в вакууме и ты нам покажешь, как этот "невероятно досадный недостаток" нам может помешать. Какие такие фендибоберные агрегаты нам необходимы вообще и в контексте топика в частности?
L>>Пример я уже приводил, вполне обыденный, а комментарий относился не конкретно к тебе обсуждение, а вообще.
___>Ну по min и всему аналогичному — здесь все понятно. При модификациях исходных таблиц представления, для функции min требуется пересчет всей группировки, куда относятся модифицируемые данные. Для sum и count же достаточно прибавить/вычесть из текущего значения группировки.
Неправда, min и max также ассоциативны, как sum и count.
min(x1,x2...xn) = min(x1, min(x2...xn))
Просто для min и max не требуется индексированное представление. Нужные значения выбираются из подходящего индекса если он существует при запросе к самой таблице.
Здравствуйте, gandjustas, Вы писали:
L>>>Пример я уже приводил, вполне обыденный, а комментарий относился не конкретно к тебе обсуждение, а вообще.
___>>Ну по min и всему аналогичному — здесь все понятно. При модификациях исходных таблиц представления, для функции min требуется пересчет всей группировки, куда относятся модифицируемые данные. Для sum и count же достаточно прибавить/вычесть из текущего значения группировки. G>Неправда, min и max также ассоциативны, как sum и count. G>min(x1,x2...xn) = min(x1, min(x2...xn))
А при чем тут ассоциативность? Как она поможет например, при удалении данных, когда по min(x1,x2...xn) нужно будет узнать min(x2...xn)?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
L>>>>Пример я уже приводил, вполне обыденный, а комментарий относился не конкретно к тебе обсуждение, а вообще.
___>>>Ну по min и всему аналогичному — здесь все понятно. При модификациях исходных таблиц представления, для функции min требуется пересчет всей группировки, куда относятся модифицируемые данные. Для sum и count же достаточно прибавить/вычесть из текущего значения группировки. G>>Неправда, min и max также ассоциативны, как sum и count. G>>min(x1,x2...xn) = min(x1, min(x2...xn))
L>А при чем тут ассоциативность? Как она поможет например, при удалении данных, когда по min(x1,x2...xn) нужно будет узнать min(x2...xn)?
Хм... а вот про удаление я не подумал.
Здравствуйте, gandjustas, Вы писали:
G>Ну вы же понимаете что подавляющее большинство приложений таких проблем не увидит,
согласен полностью, я уже говорил что для обычных приложений для себя я вижу пользу схема-фрее, а документы расматривать в качестве Agregate root в терминах DDD G> а если увидит, то: G>1)Использовать возможности partitioning, которые позволяют часть данных выключать из обработки, что увеличит возможности вертикального масштабирования
я так понимаю это на одном сервере, т.к. например посты пользователей и комментарии к постам на разные сервера не вынесешь. G>2)Сделать аппаратный load balancing с зеркалированием
так ты сделаешь маштабирование на чтение (репликация master-slave), для того чтоб сделать маштабирование на запись надо уже master-master,
а вот маштабирование данных в рамках в rdbm сделать сложно. G>3)Тупо отказаться нормализации там где возможно понадобится делать join_ы
так это и предлагает Nosql (данные реляционные, но не все 3 нормальной формы, например есть пользователь, у него есть телефон, появляется необходимость хранить его второй-третий-энный телефон, в rdbs мы выносим в отдельную таблицу, делаем Left join, в nosql просто поле становиться списком) G>4)Отказаться от server-side joins в некоторых случаях, а использовать джоины на клиенте для подстановки справочных данных
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Ну вы же понимаете что подавляющее большинство приложений таких проблем не увидит, C>согласен полностью, я уже говорил что для обычных приложений для себя я вижу пользу схема-фрее, а документы расматривать в качестве Agregate root в терминах DDD
Сама концепция агрегатов и рутов — зло. В зависимости от требований рутом может стать то одна запись, то другая. А требования могут меняться со временем.
Например интернет магазин. Рутом можно сделать заказ, но внезапно появляется требование выводить самые продаваемые товары и рутом уже становится Товар. А в другом случае рутом станет пользователь. Таким образом в агрегат попадает или вся база, или надо сущности растаскивать по отдельным "таблицам".
Запихивание таких агрегатов в БД приводит к тому что надо заранее знать все запросы, потом менять структуру дороговато выйдет.
G>> а если увидит, то: G>>1)Использовать возможности partitioning, которые позволяют часть данных выключать из обработки, что увеличит возможности вертикального масштабирования C>я так понимаю это на одном сервере, т.к. например посты пользователей и комментарии к постам на разные сервера не вынесешь.
Разные patition_ы можно создавать в разных filegroup, которые лежат на разных дисках.
G>>2)Сделать аппаратный load balancing с зеркалированием C>так ты сделаешь маштабирование на чтение (репликация master-slave), для того чтоб сделать маштабирование на запись надо уже master-master, C>а вот маштабирование данных в рамках в rdbm сделать сложно.
Обычно чтение это 98% запросов к БД.
G>>3)Тупо отказаться нормализации там где возможно понадобится делать join_ы C>так это и предлагает Nosql (данные реляционные, но не все 3 нормальной формы, например есть пользователь, у него есть телефон, появляется необходимость хранить его второй-третий-энный телефон, в rdbs мы выносим в отдельную таблицу, делаем Left join, в nosql просто поле становиться списком)
Реляционность предполагает регулярную структуру. Для каждого поля тип заранее определен. Это позволяет строить индексы и прозрачно их использовать для оптимизации запросов.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, cadet354, Вы писали:
C>>Здравствуйте, gandjustas, Вы писали:
G>>>Ну вы же понимаете что подавляющее большинство приложений таких проблем не увидит, C>>согласен полностью, я уже говорил что для обычных приложений для себя я вижу пользу схема-фрее, а документы расматривать в качестве Agregate root в терминах DDD G>Сама концепция агрегатов и рутов — зло. В зависимости от требований рутом может стать то одна запись, то другая. А требования могут меняться со временем. G>Например интернет магазин. Рутом можно сделать заказ, но внезапно появляется требование выводить самые продаваемые товары и рутом уже становится Товар. А в другом случае рутом станет пользователь. Таким образом в агрегат попадает или вся база, или надо сущности растаскивать по отдельным "таблицам".
ну все в одну сущность засовывать не надо, товар и его характеристики это одна сущность (документ) (сколько таблиц это будет в реляционной модели сам понимаешь), вторая сущность (документ) это заказ со своими характеристиками.
G>Реляционность предполагает регулярную структуру. Для каждого поля тип заранее определен. Это позволяет строить индексы и прозрачно их использовать для оптимизации запросов.
бизнес требования могут меняться (нужен был один тлф, а теперь несколько).
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, cadet354, Вы писали:
c>> забывают добавить что плохо только в MySQL/Postgre ?
AB>А MySQL-то за что?
года 4 назад намучался с master-master на InnoDB, с тех пор возможно все стало и хорошо.
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, cadet354, Вы писали:
C>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Ну вы же понимаете что подавляющее большинство приложений таких проблем не увидит, C>>>согласен полностью, я уже говорил что для обычных приложений для себя я вижу пользу схема-фрее, а документы расматривать в качестве Agregate root в терминах DDD G>>Сама концепция агрегатов и рутов — зло. В зависимости от требований рутом может стать то одна запись, то другая. А требования могут меняться со временем. G>>Например интернет магазин. Рутом можно сделать заказ, но внезапно появляется требование выводить самые продаваемые товары и рутом уже становится Товар. А в другом случае рутом станет пользователь. Таким образом в агрегат попадает или вся база, или надо сущности растаскивать по отдельным "таблицам". C>ну все в одну сущность засовывать не надо, товар и его характеристики это одна сущность (документ) (сколько таблиц это будет в реляционной модели сам понимаешь)
Чаще всего одна.
C>вторая сущность (документ) это заказ со своими характеристиками.
Позиции заказа являются характеристиками заказа? А если нам нужно считать продажи по товарам за последний месяц?
G>>Реляционность предполагает регулярную структуру. Для каждого поля тип заранее определен. Это позволяет строить индексы и прозрачно их использовать для оптимизации запросов. C>бизнес требования могут меняться (нужен был один тлф, а теперь несколько).
Ну записали в одно поле через запятую
Здравствуйте, 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++.
Здравствуйте, gandjustas, Вы писали:
G>И на каждое добавление голоса на нужно обновлять "пользователя" в хранилище?
Да. Это проблема?
G>И как в таком случае считать голоса для вопросов\ответов?
Точно так же. Нас же никто не заставляет нормализовать данные. Будем хранить в каждом посте и каждом комменте коллекцию голосов, раз уж нам важна история.
G>Я в первом посте привел юзкейсы. Можешь свой вариант NoSQL хранилища привести для них.
Я ссылку приведу, open source клон StackOverflow использующий mongoDB
Здравствуйте, gandjustas, Вы писали:
G>Горизонтальная масштабируемость съела моск.
Потому что масштабироваться надо, а масштабироваться вертикально дорого.
G>Интересно будет посмотреть куда оно все пойдет когда SSD массово войдут на рынок.
Туда же. Просто БД будет упираться не не в диск, а куда-нибудь еще.
Здравствуйте, Head Ache, Вы писали:
HA>Здравствуйте, gandjustas, Вы писали:
G>>Подход RDB очевиден: G>>1)создать нормализованные таблицы G>>2)сделать индексированные view, считающие количество голосов по ответам, комментам, пользователям G>>3)Сделать индексированное view для подсчета количества ответов и голосов по вопросам G>>4)В случае невозможности сделать view — пересчитывать в триггерах G>>5)Понаделать индексов чтобы не было ни одного scan для выборки
G>>Такая БД влезет примерно в 100 гб (в зависимости от длины вопросов и ответов). Один хороший сервак должен потянуть такую базу.
G>>Что нам предложит NoSQL подход в данном случае?
HA>почему ты противопоставляешь?
HA>см. http://ru.wikipedia.org/wiki/NoSQL
HA>Или у тебя другое определение NoSql ?
Мне вообще-то все равно. Но есть некоторые личности которые не просто противопоставляют, но и утверждают что NoSQL рулит.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>И на каждое добавление голоса на нужно обновлять "пользователя" в хранилище? M>Да. Это проблема?
Ага, см ниже.
G>>И как в таком случае считать голоса для вопросов\ответов? M>Точно так же. Нас же никто не заставляет нормализовать данные. Будем хранить в каждом посте и каждом комменте коллекцию голосов, раз уж нам важна история.
А если удалится вопрос вместе с голосами?
Поддерживать денормализацию руками — крайне неблагодарное занятие, надо его избегать.
G>>Я в первом посте привел юзкейсы. Можешь свой вариант NoSQL хранилища привести для них. M>Я ссылку приведу, open source клон StackOverflow использующий mongoDB
Спасибо, посмотрю.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Горизонтальная масштабируемость съела моск. M>Потому что масштабироваться надо, а масштабироваться вертикально дорого.
Вертикально дешевле, чем горизонтально
G>>Интересно будет посмотреть куда оно все пойдет когда SSD массово войдут на рынок. M>Туда же. Просто БД будет упираться не не в диск, а куда-нибудь еще.
Это "еще куда-нибудь" уже давно обогнало диски. У вращающихся магнитных жестких дисков ооооочень большое время поиска, если его в несколько раз сократить, то то можно добиться пропорционального прироста производительности.
Здравствуйте, gandjustas, Вы писали:
G>Мне вообще-то все равно. Но есть некоторые личности которые не просто противопоставляют, но и утверждают что NoSQL рулит.
Для этого даже не надо искать каких-то примеров, достаточно проанализировать слабые места.
1. Алгоритмы индексации, поиска и т.д. — могут быть неэффективными в некоторых случаях.
Здесь действительно вариант NoSQL: т.е. даже при хранении данных в реляционной базе, для поиска решения используются внешние процедуры,
вроде поиска отрицательных циклов в графе или потока наименьшей стоимости. СУБД — просто удобный источник данных,
набор файлов на диске может его заменить.
2. Требования, которым удовлетворяет движок СУБД, избыточны для прикладной задачи: например, достаточно хранить данные в оперативной памяти,
или есть возможность обойтись без транзакций в "стиле СУБД", т.е. с образованием "огромного такого" rollback segment-a, и т.д.
Надеюсь, не надо говорить о том, какой прирост производительности может дать ослабление требований (конечно, если сей факт имеет место быть)?
3. Необходимость постоянно парсить SQL процедуры — в принципе, решается компиляцией, но в некоторых случаях может быть проблемой.
Вывод: на 50% личности может и правы, но скорее всего, не было грамотного решения конкретной задачи.
Здравствуйте, Head Ache, Вы писали:
HA>Здравствуйте, gandjustas, Вы писали:
G>>Мне вообще-то все равно. Но есть некоторые личности которые не просто противопоставляют, но и утверждают что NoSQL рулит.
HA>Для этого даже не надо искать каких-то примеров, достаточно проанализировать слабые места.
HA>1. Алгоритмы индексации, поиска и т.д. — могут быть неэффективными в некоторых случаях. HA>Здесь действительно вариант NoSQL: т.е. даже при хранении данных в реляционной базе, для поиска решения используются внешние процедуры, HA>вроде поиска отрицательных циклов в графе или потока наименьшей стоимости. СУБД — просто удобный источник данных, HA>набор файлов на диске может его заменить.
Алгоритмы никак не связаны с NoSQL. Они абсолютно одинаково будут работать на любом хранилище.
Более того с помощью расширений в СУБД можно некоторые алгоритмы использовать прямо в SQL.
HA>2. Требования, которым удовлетворяет движок СУБД, избыточны для прикладной задачи: например, достаточно хранить данные в оперативной памяти, HA>или есть возможность обойтись без транзакций в "стиле СУБД", т.е. с образованием "огромного такого" rollback segment-a, и т.д.
Ну-ну, в каком месте можно без ACID транзакций обойтись? Особенно интересует веб, как основная область приложения NoSQL.
HA>Надеюсь, не надо говорить о том, какой прирост производительности может дать ослабление требований (конечно, если сей факт имеет место быть)?
А нафига нужен прирост производительности при ненадежном хранении? Только для кеширования, а в основное хранилище будет в СУБД.
HA>3. Необходимость постоянно парсить SQL процедуры — в принципе, решается компиляцией, но в некоторых случаях может быть проблемой. HA>Вывод: на 50% личности может и правы, но скорее всего, не было грамотного решения конкретной задачи.
Они могут быть правы примерно на 1%, но нас как раз интересует 99% остальные.
Я поэтому и привел кейсы в первом посте. stackoverflow довольно типовой веб-два-нольный сайт с большой нагрузкой. как выяснилось сделать такое на NoSQL мало кто способен.
Здравствуйте, gandjustas, Вы писали:
G>Алгоритмы никак не связаны с NoSQL. Они абсолютно одинаково будут работать на любом хранилище. G>Более того с помощью расширений в СУБД можно некоторые алгоритмы использовать прямо в SQL.
Я имел в виду, что можно поиметь проблемы с производительностью, если писать на встроенном
языке алгоритмы со сложностью выше O(N^2). Ну, если есть API, которое позволяет обмен данными, тогда проблемы нет.
HA>>2. Требования, которым удовлетворяет движок СУБД, избыточны для прикладной задачи: например, достаточно хранить данные в оперативной памяти, HA>>или есть возможность обойтись без транзакций в "стиле СУБД", т.е. с образованием "огромного такого" rollback segment-a, и т.д. G>Ну-ну, в каком месте можно без ACID транзакций обойтись? Особенно интересует веб, как основная область приложения NoSQL. HA>>Надеюсь, не надо говорить о том, какой прирост производительности может дать ослабление требований (конечно, если сей факт имеет место быть)? G>А нафига нужен прирост производительности при ненадежном хранении? Только для кеширования, а в основное хранилище будет в СУБД.
Почему хранение сразу станет ненадежным? ACID ведь это не какое-то волшебное свойство только промышленных СУБД.
Я имел в виду, что ручками сделанная синхронизация с учетом специфики приложения может быть оправдана.
Кому сильно надо, именно так и сделают.
HA>>3. Необходимость постоянно парсить SQL процедуры — в принципе, решается компиляцией, но в некоторых случаях может быть проблемой. HA>>Вывод: на 50% личности может и правы, но скорее всего, не было грамотного решения конкретной задачи. G>Они могут быть правы примерно на 1%, но нас как раз интересует 99% остальные.
G>Я поэтому и привел кейсы в первом посте. stackoverflow довольно типовой веб-два-нольный сайт с большой нагрузкой. как выяснилось сделать такое на NoSQL мало кто способен.
Мало исполнителей с техникой кодирования на должном уровне. И кому это надо, если на стандартных движках и так работает.
Более интересный пример — системы real-time, управление электростанцией и т.п.
Когда ограничивается время реакции системы, гарантия не более 1 мс (жесткий real-time) или 10 мс (уже мягкий).
Тем не менее, как-то надо успеть записать в журналы, подать управляющие сигналы и т.д.
Здравствуйте, Head Ache, Вы писали:
HA>Здравствуйте, gandjustas, Вы писали:
G>>Алгоритмы никак не связаны с NoSQL. Они абсолютно одинаково будут работать на любом хранилище. G>>Более того с помощью расширений в СУБД можно некоторые алгоритмы использовать прямо в SQL. HA>Я имел в виду, что можно поиметь проблемы с производительностью, если писать на встроенном HA>языке алгоритмы со сложностью выше O(N^2). Ну, если есть API, которое позволяет обмен данными, тогда проблемы нет.
HA>>>2. Требования, которым удовлетворяет движок СУБД, избыточны для прикладной задачи: например, достаточно хранить данные в оперативной памяти, HA>>>или есть возможность обойтись без транзакций в "стиле СУБД", т.е. с образованием "огромного такого" rollback segment-a, и т.д. G>>Ну-ну, в каком месте можно без ACID транзакций обойтись? Особенно интересует веб, как основная область приложения NoSQL. HA>>>Надеюсь, не надо говорить о том, какой прирост производительности может дать ослабление требований (конечно, если сей факт имеет место быть)? G>>А нафига нужен прирост производительности при ненадежном хранении? Только для кеширования, а в основное хранилище будет в СУБД.
HA>Почему хранение сразу станет ненадежным? ACID ведь это не какое-то волшебное свойство только промышленных СУБД. HA>Я имел в виду, что ручками сделанная синхронизация с учетом специфики приложения может быть оправдана. HA>Кому сильно надо, именно так и сделают.
Только тормозить оно будет сильнее, чем готовое решение на СУБД.
HA>>>3. Необходимость постоянно парсить SQL процедуры — в принципе, решается компиляцией, но в некоторых случаях может быть проблемой. HA>>>Вывод: на 50% личности может и правы, но скорее всего, не было грамотного решения конкретной задачи. G>>Они могут быть правы примерно на 1%, но нас как раз интересует 99% остальные.
G>>Я поэтому и привел кейсы в первом посте. stackoverflow довольно типовой веб-два-нольный сайт с большой нагрузкой. как выяснилось сделать такое на NoSQL мало кто способен. HA>Мало исполнителей с техникой кодирования на должном уровне. И кому это надо, если на стандартных движках и так работает.
Так я же не прошу готовое решение показывать, я предложил накидать схему хранения данных с помощью NoSQL.
HA>Более интересный пример — системы real-time, управление электростанцией и т.п.
А причем тут NoSQL и реал-тайм? Хоть одна NoSQL база дает real-time гарантии?
HA>Когда ограничивается время реакции системы, гарантия не более 1 мс (жесткий real-time) или 10 мс (уже мягкий).
Определение жесткого и мягкого реалтайма не от времени зависят.
HA>Тем не менее, как-то надо успеть записать в журналы, подать управляющие сигналы и т.д.
Для этого нужна RT OS. Вот интересно есть ли NoSQL решения под QNX с гарантиями?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Head Ache, Вы писали:
HA>>Здравствуйте, gandjustas, Вы писали:
HA>>Почему хранение сразу станет ненадежным? ACID ведь это не какое-то волшебное свойство только промышленных СУБД. HA>>Я имел в виду, что ручками сделанная синхронизация с учетом специфики приложения может быть оправдана. HA>>Кому сильно надо, именно так и сделают. G>Только тормозить оно будет сильнее, чем готовое решение на СУБД.
Готовое решение создано в расчете на худший случай и может тормозить из-за необоснованных ограничений,
которых нет в конкретной ситуации. Что и имелось в виду в словах "сильно надо".
Как, например, заставить движок БД использовать блокировку типа "один писатель-много читателей" для
какой-то отдельно взятой таблицы внутри транзакции.
HA>>Более интересный пример — системы real-time, управление электростанцией и т.п. G>А причем тут NoSQL и реал-тайм? Хоть одна NoSQL база дает real-time гарантии?
Готового кирпича, подобного Oracle или SQL server — не существует.
Существуют отдельные модули, дающие гарантию на ту или иную операцию,
из них можно собрать систему под конкретную задачу (если повезет, конечно )
Очевидно, что для произвольно взятой БД никаких гарантий реал-тайма не может быть в принципе.
Здравствуйте, Head Ache, Вы писали:
HA>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Head Ache, Вы писали:
HA>>>Здравствуйте, gandjustas, Вы писали:
HA>>>Почему хранение сразу станет ненадежным? ACID ведь это не какое-то волшебное свойство только промышленных СУБД. HA>>>Я имел в виду, что ручками сделанная синхронизация с учетом специфики приложения может быть оправдана. HA>>>Кому сильно надо, именно так и сделают. G>>Только тормозить оно будет сильнее, чем готовое решение на СУБД. HA>Готовое решение создано в расчете на худший случай и может тормозить из-за необоснованных ограничений, HA>которых нет в конкретной ситуации. Что и имелось в виду в словах "сильно надо".
В СУБД можно поотключать "необоснованные ограничения" когда надо.
С другой стороны ограничения в NoSQL обойти уже нельзя. Например в отсутствии ACID становится крайне сложно гарантировать что-то.
HA>Как, например, заставить движок БД использовать блокировку типа "один писатель-много читателей" для HA>какой-то отдельно взятой таблицы внутри транзакции.
Изучи как работают блокировки в SQL Server. Оно по-умолчанию так.
HA>>>Более интересный пример — системы real-time, управление электростанцией и т.п. G>>А причем тут NoSQL и реал-тайм? Хоть одна NoSQL база дает real-time гарантии?
HA>Готового кирпича, подобного Oracle или SQL server — не существует. HA>Существуют отдельные модули, дающие гарантию на ту или иную операцию, HA>из них можно собрать систему под конкретную задачу (если повезет, конечно )
Это что-то из области фантастики.
HA>Очевидно, что для произвольно взятой БД никаких гарантий реал-тайма не может быть в принципе.
Мне что-то неочевидно такое утверждение. Доказать сможешь?
Здравствуйте, gandjustas, Вы писали:
HA>>>>Почему хранение сразу станет ненадежным? ACID ведь это не какое-то волшебное свойство только промышленных СУБД. HA>>>>Я имел в виду, что ручками сделанная синхронизация с учетом специфики приложения может быть оправдана. HA>>>>Кому сильно надо, именно так и сделают. G>>>Только тормозить оно будет сильнее, чем готовое решение на СУБД. HA>>Готовое решение создано в расчете на худший случай и может тормозить из-за необоснованных ограничений, HA>>которых нет в конкретной ситуации. Что и имелось в виду в словах "сильно надо". G>В СУБД можно поотключать "необоснованные ограничения" когда надо.
Вот тогда ACID и пропадет. Потому что нет избирательности — меняется режим транзакции и привет.
HA>>Как, например, заставить движок БД использовать блокировку типа "один писатель-много читателей" для HA>>какой-то отдельно взятой таблицы внутри транзакции. G>Изучи как работают блокировки в SQL Server. Оно по-умолчанию так.
Не знаю, исходников у меня нет. А реализаций под один и тот же функционал миллион придумать можно.
HA>>>>Более интересный пример — системы real-time, управление электростанцией и т.п. G>>>А причем тут NoSQL и реал-тайм? Хоть одна NoSQL база дает real-time гарантии?
HA>>Готового кирпича, подобного Oracle или SQL server — не существует. HA>>Существуют отдельные модули, дающие гарантию на ту или иную операцию, HA>>из них можно собрать систему под конкретную задачу (если повезет, конечно ) G>Это что-то из области фантастики.
То есть не существует ни одного модуля? Или ни одной системы?
HA>>Очевидно, что для произвольно взятой БД никаких гарантий реал-тайма не может быть в принципе. G>Мне что-то неочевидно такое утверждение. Доказать сможешь?
Может, сам попробуешь доказать обратное?
И что вообще здесь надо доказывать?
Здравствуйте, Head Ache, Вы писали:
HA>Здравствуйте, gandjustas, Вы писали:
HA>>>>>Почему хранение сразу станет ненадежным? ACID ведь это не какое-то волшебное свойство только промышленных СУБД. HA>>>>>Я имел в виду, что ручками сделанная синхронизация с учетом специфики приложения может быть оправдана. HA>>>>>Кому сильно надо, именно так и сделают. G>>>>Только тормозить оно будет сильнее, чем готовое решение на СУБД. HA>>>Готовое решение создано в расчете на худший случай и может тормозить из-за необоснованных ограничений, HA>>>которых нет в конкретной ситуации. Что и имелось в виду в словах "сильно надо". G>>В СУБД можно поотключать "необоснованные ограничения" когда надо. HA>Вот тогда ACID и пропадет. Потому что нет избирательности — меняется режим транзакции и привет.
Пропадает сериализуемость, а не acid. Учи матчасть.
HA>>>Как, например, заставить движок БД использовать блокировку типа "один писатель-много читателей" для HA>>>какой-то отдельно взятой таблицы внутри транзакции. G>>Изучи как работают блокировки в SQL Server. Оно по-умолчанию так. HA>Не знаю, исходников у меня нет. А реализаций под один и тот же функционал миллион придумать можно.
В документации есть.
HA>>>>>Более интересный пример — системы real-time, управление электростанцией и т.п. G>>>>А причем тут NoSQL и реал-тайм? Хоть одна NoSQL база дает real-time гарантии?
HA>>>Готового кирпича, подобного Oracle или SQL server — не существует. HA>>>Существуют отдельные модули, дающие гарантию на ту или иную операцию, HA>>>из них можно собрать систему под конкретную задачу (если повезет, конечно ) G>>Это что-то из области фантастики. HA>То есть не существует ни одного модуля? Или ни одной системы?
Не знаю, приведи ссылки.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Head Ache, Вы писали:
HA>>Здравствуйте, gandjustas, Вы писали:
HA>>>>>>Почему хранение сразу станет ненадежным? ACID ведь это не какое-то волшебное свойство только промышленных СУБД. HA>>>>>>Я имел в виду, что ручками сделанная синхронизация с учетом специфики приложения может быть оправдана. HA>>>>>>Кому сильно надо, именно так и сделают. G>>>>>Только тормозить оно будет сильнее, чем готовое решение на СУБД. HA>>>>Готовое решение создано в расчете на худший случай и может тормозить из-за необоснованных ограничений, HA>>>>которых нет в конкретной ситуации. Что и имелось в виду в словах "сильно надо". G>>>В СУБД можно поотключать "необоснованные ограничения" когда надо. HA>>Вот тогда ACID и пропадет. Потому что нет избирательности — меняется режим транзакции и привет. G>Пропадает сериализуемость, а не acid. Учи матчасть.
У меня сейчас нет времени на достаточно показательный пример,
может сделаю, когда будет время и желание.
HA>>>>Готового кирпича, подобного Oracle или SQL server — не существует. HA>>>>Существуют отдельные модули, дающие гарантию на ту или иную операцию, HA>>>>из них можно собрать систему под конкретную задачу (если повезет, конечно ) G>>>Это что-то из области фантастики. HA>>То есть не существует ни одного модуля? Или ни одной системы? G>Не знаю, приведи ссылки.
если сильно интересно — погугли Zip RTDBMS, EagleSpeed RTDMS, Comet RTDBMS
повторяю, системы реального времени делаются под конкретную задачу, и это комплексное решение,
с определенным оборудованием, ОС, а не просто какой-то отдельно взятый модуль.
Здравствуйте, gandjustas, Вы писали:
G>Если сложно для такой, то можно привести другой реальный пример (другой сайт), где NoSQL будет выглядеть хорошо.
Фейсбук подойдет?
Они там используют мускуль, но только в режиме "получить значение по ключу". Никаких джойнов и прочей ереси.
Здравствуйте, Сергей Туленцев, Вы писали:
СТ>Здравствуйте, gandjustas, Вы писали:
G>>Если сложно для такой, то можно привести другой реальный пример (другой сайт), где NoSQL будет выглядеть хорошо.
СТ>Фейсбук подойдет?
это из разряда софта для атомных станций СТ>Они там используют мускуль, но только в режиме "получить значение по ключу". Никаких джойнов и прочей ереси.
а Cassandra зачем была ими написана?
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, Сергей Туленцев, Вы писали:
СТ>>Здравствуйте, gandjustas, Вы писали:
G>>>Если сложно для такой, то можно привести другой реальный пример (другой сайт), где NoSQL будет выглядеть хорошо.
СТ>>Фейсбук подойдет? C>это из разряда софта для атомных станций СТ>>Они там используют мускуль, но только в режиме "получить значение по ключу". Никаких джойнов и прочей ереси. C>а Cassandra зачем была ими написана?
Кассандра у них вроде только для поиска по инбоксу используется. Индексы. Ничего критичного.
G>В таблице Articles 100000 записей, Tags — 3000, в ArticleTags около 120000 равномерно распределены по разным тегам и статьям.
тест твой полная липа, у тебя каждый тэг используется раз эдак 30. Конечно тут будут рулить джойны.
Более реальная картина это Articles 100к , Tags — 100, в ArticleTags — 1М, и вот тут этот подход будет сосать
Здравствуйте, Enomay, Вы писали:
G>>1)создать нормализованные таблицы
E>собственно это та причина, по которой твой stackoverflow и не взлетит.
Он именно так и взлетел
G>>Что нам предложит NoSQL подход в данном случае?
E>всё то же самое, все те же view. только скорость работы выше.
Только я могу для MS SQL генерить запросы в коде с помощью Linq, а тебе заранее надо будет их в индексы БД прописать. Причем далеко не все NoSQL базы умеют синхронно индексы пересчитывать синхронно.
E>другое дело что без кеширования всё равно не взлетит.
Именно так и взлетело
А вообще чего языком чесать. дампы Stackoverflow доступны, качай, делай решение, показывай. Интерфейс не нужен, только структура. данные и забеги.
Здравствуйте, rm822, Вы писали: G>>В таблице Articles 100000 записей, Tags — 3000, в ArticleTags около 120000 равномерно распределены по разным тегам и статьям. R>тест твой полная липа, у тебя каждый тэг используется раз эдак 30. Конечно тут будут рулить джойны. R>Более реальная картина это Articles 100к , Tags — 100, в ArticleTags — 1М, и вот тут этот подход будет сосать
Той базы у меня не осталось, но мне не впадлу написать SQL для тестов
Структура
Скрытый текст
CREATE TABLE [dbo].[Articles](
[Id] [int] IDENTITY(1,1) NOT NULL,
[Title] [nvarchar](100) NULL,
CONSTRAINT [PK__Articles__3214EC077F60ED59] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Tags](
[Id] [int] IDENTITY(1,1) NOT NULL,
[Name] [nvarchar](100) NULL,
CONSTRAINT [PK__Tags__3214EC0707020F21] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[TagArticles](
[Tag_Id] [int] NOT NULL,
[Article_Id] [int] NOT NULL,
PRIMARY KEY CLUSTERED
(
[Tag_Id] ASC,
[Article_Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[TagArticles] WITH CHECK ADD CONSTRAINT [Tag_Articles_Source] FOREIGN KEY([Tag_Id])
REFERENCES [dbo].[Tags] ([Id])
ON DELETE CASCADE
GO
ALTER TABLE [dbo].[TagArticles] CHECK CONSTRAINT [Tag_Articles_Source]
GO
ALTER TABLE [dbo].[TagArticles] WITH CHECK ADD CONSTRAINT [Tag_Articles_Target] FOREIGN KEY([Article_Id])
REFERENCES [dbo].[Articles] ([Id])
ON DELETE CASCADE
GO
ALTER TABLE [dbo].[TagArticles] CHECK CONSTRAINT [Tag_Articles_Target]
Заполнение
Declare @counter int
Set @counter = 0
While @counter < 100000
Begin
insert Articles(Title) values('a'+STR(@counter))
Set @counter = @counter + 1
End
Set @counter = 0
While @counter < 100
Begin
insert Tags(Name) values('t'+STR(@counter))
Set @counter = @counter + 1
End
insert into TagArticles(Tag_Id, Article_Id)
select top 1000000 t.Id, a.Id from Articles a, Tags t order by NEWID()
Запрос
select a.Id, a.Title from Articles a
join [TagArticles] at1 on a.Id = at1.Article_Id
join [TagArticles] at2 on a.Id = at2.Article_Id
join [TagArticles] at3 on a.Id = at3.Article_Id
join Tags as t1 on at1.Tag_Id = t1.Id
join Tags as t2 on at2.Tag_Id = t2.Id
join Tags as t3 on at3.Tag_Id = t3.Id
where t1.Name = 't 9' and t2.Name = 't 70' and t3.Name = 't 99'
Время ожидания при ответе сервера 337 336 346 339.6667
Это миллисекунды есличо.
База MS SQL Express 2008r2 with advanced services. Ноут у меня помощнее стал: 8 ядер (Express использует одно) и 8 гб памяти (Express использует один)
Оптимизаций не проводилось, схема тупо сгенерирована Entity Framework.
G>>>1)создать нормализованные таблицы E>>собственно это та причина, по которой твой stackoverflow и не взлетит. G>Он именно так и взлетел
была статья, где они писали о денормализации в своей базе для увеличения производительности.
G>>>Что нам предложит NoSQL подход в данном случае? E>>всё то же самое, все те же view. только скорость работы выше. G>Только я могу для MS SQL генерить запросы в коде с помощью Linq, а тебе заранее надо будет их в индексы БД прописать. Причем далеко не все NoSQL базы умеют синхронно индексы пересчитывать синхронно.
если мы будем рассматривать RavenDB, то запросы так же пишутся на linq. индексы можно как создавать заранее, так и использовать динамически сгенерированные.
индексы перестраиваются асинхронно, что позволяет достичь высокой скорости работы.
в общем-то для других баз так же есть поддержка linq, в том или ином виде. кто как пилит.
G>Так это 1)ноут с небыстрым диском 2)Express версия 3)никакой оптимизации 4)нет кеширования
дешевые отмазки
300мс у тебя чистое процессорное время, все данные в кэше, обращений к диску нет вообще
G>В реальном приложении на реальном железе в 100 раз ускорить — не проблема.
ну покажи класс, ща посмотрим как ты 300мс процессорного времени сократишь до 3х
Здравствуйте, rm822, Вы писали:
G>>Так это 1)ноут с небыстрым диском 2)Express версия 3)никакой оптимизации 4)нет кеширования R>дешевые отмазки
Правда жизни.
R>300мс у тебя чистое процессорное время, все данные в кэше, обращений к диску нет вообще
Так тем более. На реальном серваке это будет не 300, а 30мс или того меньше и ядер будет задействовано побольше.
G>>В реальном приложении на реальном железе в 100 раз ускорить — не проблема. R>ну покажи класс, ща посмотрим как ты 300мс процессорного времени сократишь до 3х
У меня ни реального железа, ни реального приложения нет. Одно добавление кеша на такие запросы сделает систему в 100 раз быстрее.
Давай лучше ты покажи класс на NoSQL системе. Те же самые условия, такой же запрос. 300 мс ответа и консистентные результаты.
Здравствуйте, Enomay, Вы писали:
G>>>>1)создать нормализованные таблицы E>>>собственно это та причина, по которой твой stackoverflow и не взлетит. G>>Он именно так и взлетел
E>была статья, где они писали о денормализации в своей базе для увеличения производительности.
Ага, через 2 года после запуска Когда объемы стали в разы больше, чем в любом написаном тобой приложении.
G>>>>Что нам предложит NoSQL подход в данном случае? E>>>всё то же самое, все те же view. только скорость работы выше. G>>Только я могу для MS SQL генерить запросы в коде с помощью Linq, а тебе заранее надо будет их в индексы БД прописать. Причем далеко не все NoSQL базы умеют синхронно индексы пересчитывать синхронно.
E>если мы будем рассматривать RavenDB, то запросы так же пишутся на linq. индексы можно как создавать заранее, так и использовать динамически сгенерированные.
Мне RavenDB очень нравится. Только сырой он. Посмотри веб-касты, он умудряется глючить по 3 раза за 20 минут. Для продакшена такое вообще не пойдет. Пока единственное "промышленное" применение RavenDB — блог его автора.
E>индексы перестраиваются асинхронно, что позволяет достичь высокой скорости работы.
Ага, и забить на консистентность результатов... Такой же высокой скорости можно и в SQL добиться разделив хранилище на 2 — транзакционное и read-only с nolock, и сделать асинхронное перемещение.
E>в общем-то для других баз так же есть поддержка linq, в том или ином виде. кто как пилит.
Поддержка linq не решает если adhoc запросы не поддерживаются. А они поддерживаются единицами.
G>>>>>1)создать нормализованные таблицы E>>>>собственно это та причина, по которой твой stackoverflow и не взлетит. G>>>Он именно так и взлетел E>>была статья, где они писали о денормализации в своей базе для увеличения производительности. G>Ага, через 2 года после запуска Когда объемы стали в разы больше, чем в любом написаном тобой приложении.
ну конечно, ты ведь знаешь у кого какие объемы
у меня например, 25к записей в секунду. ms sql умирает
E>>если мы будем рассматривать RavenDB, то запросы так же пишутся на linq. индексы можно как создавать заранее, так и использовать динамически сгенерированные. G>Мне RavenDB очень нравится. Только сырой он. Посмотри веб-касты, он умудряется глючить по 3 раза за 20 минут. Для продакшена такое вообще не пойдет. Пока единственное "промышленное" применение RavenDB — блог его автора.
может быть они используют нестабильную версию?
люди юзают в продакшене.
E>>индексы перестраиваются асинхронно, что позволяет достичь высокой скорости работы. G>Ага, и забить на консистентность результатов... Такой же высокой скорости можно и в SQL добиться разделив хранилище на 2 — транзакционное и read-only с nolock, и сделать асинхронное перемещение.
данные неконсистенты уже в момент их отображения.
собственно, разбитием на 2 хранилища сейчас все и занимаются. только первым почему-то NoSQL выбирают. а вторым денормализованную РСУБД.
E>>в общем-то для других баз так же есть поддержка linq, в том или ином виде. кто как пилит. G>Поддержка linq не решает если adhoc запросы не поддерживаются. А они поддерживаются единицами.
Здравствуйте, Enomay, Вы писали:
G>>>>>>1)создать нормализованные таблицы E>>>>>собственно это та причина, по которой твой stackoverflow и не взлетит. G>>>>Он именно так и взлетел E>>>была статья, где они писали о денормализации в своей базе для увеличения производительности. G>>Ага, через 2 года после запуска Когда объемы стали в разы больше, чем в любом написаном тобой приложении.
E>ну конечно, ты ведь знаешь у кого какие объемы
Статистика прямо на главной странице. Можно эмпирически по этим данным посчитать объемы.
E>у меня например, 25к записей в секунду. ms sql умирает
Покажи какая durable база не умирает? Даже в фс писать без буферизации с такой скоростью не получится.
E>>>если мы будем рассматривать RavenDB, то запросы так же пишутся на linq. индексы можно как создавать заранее, так и использовать динамически сгенерированные. G>>Мне RavenDB очень нравится. Только сырой он. Посмотри веб-касты, он умудряется глючить по 3 раза за 20 минут. Для продакшена такое вообще не пойдет. Пока единственное "промышленное" применение RavenDB — блог его автора.
E>может быть они используют нестабильную версию? E>люди юзают в продакшене.
В продакшене юзают или несерьезные сайты (блоги), или те кто её написали и знают особенности.
E>>>индексы перестраиваются асинхронно, что позволяет достичь высокой скорости работы. G>>Ага, и забить на консистентность результатов... Такой же высокой скорости можно и в SQL добиться разделив хранилище на 2 — транзакционное и read-only с nolock, и сделать асинхронное перемещение.
E>данные неконсистенты уже в момент их отображения.
Нет. Неконсистентность означает что ты пишешь и сразу читаешь. Если нету конкурентного доступа то ты должен прочитать ровно то что записал.
Например увидел вопрос в форуме, свой коммент или оценку. Или свой заказ на сайте в списке заказов.
E>собственно, разбитием на 2 хранилища сейчас все и занимаются. только первым почему-то NoSQL выбирают. а вторым денормализованную РСУБД.
Кто все? Обычная РСУБД выдерживает огромные, по меркам обычного проекта, объемы данных. Там нет смысла этим заниматься.
Посмотри пример выше: поиск по тегам на 10000 статей, без всяких FTS выполняется за 300мс в реальном времени, без всякой асинхронности. При этом каждой статье примерно 10 тегов соотвествует. Возьми РСДН и посмотри распределение тегов по статьям. там плотность на порядок меньше, а именно от нее зависит скорость работы запроса.
E>>>в общем-то для других баз так же есть поддержка linq, в том или ином виде. кто как пилит. G>>Поддержка linq не решает если adhoc запросы не поддерживаются. А они поддерживаются единицами.
E>что есть "adhoc запросы" в данном контексте?
То что я могу взять A и сделать джоин с B, агрегацию по полю A.c и подзапрос по B.d
Ни одна из известных мне NoSQL баз такое сделать не позволяет. Ты должен в них заранее определить какие данные ты будешь запрашивать.
E>>собственно, разбитием на 2 хранилища сейчас все и занимаются. только первым почему-то NoSQL выбирают. а вторым денормализованную РСУБД. G>Кто все? Обычная РСУБД выдерживает огромные, по меркам обычного проекта, объемы данных. Там нет смысла этим заниматься. G>Посмотри пример выше: поиск по тегам на 10000 статей, без всяких FTS выполняется за 300мс в реальном времени, без всякой асинхронности. При этом каждой статье примерно 10 тегов соотвествует. Возьми РСДН и посмотри распределение тегов по статьям. там плотность на порядок меньше, а именно от нее зависит скорость работы запроса.
afair, в тех сырцах которые выложены, не было реализации тегов. Или уже что-то поменялось? Если ты про какой-то искуственный пример, то это микротест и относится к нему нужно соответственно. Тем более, что цифра 10000 — это просто смешно.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
E>>>собственно, разбитием на 2 хранилища сейчас все и занимаются. только первым почему-то NoSQL выбирают. а вторым денормализованную РСУБД. G>>Кто все? Обычная РСУБД выдерживает огромные, по меркам обычного проекта, объемы данных. Там нет смысла этим заниматься. G>>Посмотри пример выше: поиск по тегам на 10000 статей, без всяких FTS выполняется за 300мс в реальном времени, без всякой асинхронности. При этом каждой статье примерно 10 тегов соотвествует. Возьми РСДН и посмотри распределение тегов по статьям. там плотность на порядок меньше, а именно от нее зависит скорость работы запроса.
ANS>afair, в тех сырцах которые выложены, не было реализации тегов. Или уже что-то поменялось? Если ты про какой-то искуственный пример, то это микротест и относится к нему нужно соответственно. Тем более, что цифра 10000 — это просто смешно.
Все есть. Читай посты. 10000 — опечатка, там на нолик больше.
Какой там тест меня мало интересует. Для начала пусть какая-нить NoSQL база результат покажет на тех же объемах. Желательно без FTS. FTS и я могу сделать на lucene.
E>>у меня например, 25к записей в секунду. ms sql умирает G>Покажи какая durable база не умирает? Даже в фс писать без буферизации с такой скоростью не получится.
ну скажем MySQL справляется.
E>>может быть они используют нестабильную версию? E>>люди юзают в продакшене. G>В продакшене юзают или несерьезные сайты (блоги), или те кто её написали и знают особенности.
есть пару знакомых юзающих у клиента в продакшене. не жалуются. если, конечно, знать 1 особенность.
E>>данные неконсистенты уже в момент их отображения. G>Нет. Неконсистентность означает что ты пишешь и сразу читаешь. Если нету конкурентного доступа то ты должен прочитать ровно то что записал. G>Например увидел вопрос в форуме, свой коммент или оценку. Или свой заказ на сайте в списке заказов.
это уже детали реализации. отправив коммент, мы его можем сразу отобразить, но вот дать гарантию того, что он сохранится, не можем. и дело тут не в типа базы данных.
а можем и не отображать до тех пор, пока он не переместится во view базу.
собственно, придерживаясь Event Sourcing подхода, мы не можем и писать и читать одновременно. что, имхо, есть правильно.
E>>собственно, разбитием на 2 хранилища сейчас все и занимаются. только первым почему-то NoSQL выбирают. а вторым денормализованную РСУБД. G>Кто все? Обычная РСУБД выдерживает огромные, по меркам обычного проекта, объемы данных. Там нет смысла этим заниматься. G>Посмотри пример выше: поиск по тегам на 10000 статей, без всяких FTS выполняется за 300мс в реальном времени, без всякой асинхронности. При этом каждой статье примерно 10 тегов соотвествует. Возьми РСДН и посмотри распределение тегов по статьям. там плотность на порядок меньше, а именно от нее зависит скорость работы запроса.
это искусственные данные, и они сильно отличаются от того, что может быть на сервере.
E>>что есть "adhoc запросы" в данном контексте? G>То что я могу взять A и сделать джоин с B, агрегацию по полю A.c и подзапрос по B.d G>Ни одна из известных мне NoSQL баз такое сделать не позволяет. Ты должен в них заранее определить какие данные ты будешь запрашивать.
такое можно писать в RavenDB. такое можно делать и в других базах, хотя работать будет медленнее.
но что это даст? удобство разработки? так рано или поздно тебе в MS SQL придется делать вьюхи. что будет равносильно созданию индекса в NoSQL базе.
то есть мы ничего не выигрываем и ничего не теряем.
тем более с учетом того, что 80% данных достаются почти всегда по ключу.
G>Все есть. Читай посты. 10000 — опечатка, там на нолик больше.
G>Какой там тест меня мало интересует. Для начала пусть какая-нить NoSQL база результат покажет на тех же объемах. Желательно без FTS. FTS и я могу сделать на lucene.
где сама задача? можно попробовать сделать синтетический тест.
Здравствуйте, Enomay, Вы писали:
E>>>у меня например, 25к записей в секунду. ms sql умирает G>>Покажи какая durable база не умирает? Даже в фс писать без буферизации с такой скоростью не получится.
E>ну скажем MySQL справляется.
25K комитов в сек на одной железяке? Верится с трудом.
E>>>>у меня например, 25к записей в секунду. ms sql умирает G>>>Покажи какая durable база не умирает? Даже в фс писать без буферизации с такой скоростью не получится.
E>>ну скажем MySQL справляется.
ANS>25K комитов в сек на одной железяке? Верится с трудом.
ну не на 1
но MS SQL значительно хуже себя показывает в этом деле.
* Tags — okay, time to blow out of the bullet points for a second.
StackOverflow limits you to five tags per question (answers aren't tagged), and all five are stored in this field. For example, for question 305223, the Tags field is "<offtopic><fun><not-programming-related><jon-skeet>". It's up to you to normalize these. Sam Saffron's SoSlow utility automatically creates Tags and PostsTags tables to normalize these.
btw, Мне написало '28976 rows returned in 6427 ms'. Это нормально? С учем того, что, скорее всего, всё влазит ОЗУ.
G>Какой там тест меня мало интересует.
Зря. Это ж R/O БД. Мало кому такое интересно.
G>Для начала пусть какая-нить NoSQL база результат покажет на тех же объемах.
Вопрос не ко мне. Но, имхо, ты привратно понимаешь термин NoSql.
G>Желательно без FTS. FTS и я могу сделать на lucene.
Здравствуйте, Enomay, Вы писали:
E>>>у меня например, 25к записей в секунду. ms sql умирает G>>Покажи какая durable база не умирает? Даже в фс писать без буферизации с такой скоростью не получится.
E>ну скажем MySQL справляется.
Ох не верится. Я вот на ноуте запись в файл без буферизации прогнал, сильно меньше получилось.
E>>>данные неконсистенты уже в момент их отображения. G>>Нет. Неконсистентность означает что ты пишешь и сразу читаешь. Если нету конкурентного доступа то ты должен прочитать ровно то что записал. G>>Например увидел вопрос в форуме, свой коммент или оценку. Или свой заказ на сайте в списке заказов.
E>это уже детали реализации. отправив коммент, мы его можем сразу отобразить, но вот дать гарантию того, что он сохранится, не можем. и дело тут не в типа базы данных. E>а можем и не отображать до тех пор, пока он не переместится во view базу. E>собственно, придерживаясь Event Sourcing подхода, мы не можем и писать и читать одновременно. что, имхо, есть правильно.
не понял о чем ты? Вот мы делаем POST, потом GET. А не изменилось состояние, а потом через несколько GET мы получаем результаты. Это противоречит ожиданиям юзеров.
E>>>собственно, разбитием на 2 хранилища сейчас все и занимаются. только первым почему-то NoSQL выбирают. а вторым денормализованную РСУБД. G>>Кто все? Обычная РСУБД выдерживает огромные, по меркам обычного проекта, объемы данных. Там нет смысла этим заниматься. G>>Посмотри пример выше: поиск по тегам на 10000 статей, без всяких FTS выполняется за 300мс в реальном времени, без всякой асинхронности. При этом каждой статье примерно 10 тегов соотвествует. Возьми РСДН и посмотри распределение тегов по статьям. там плотность на порядок меньше, а именно от нее зависит скорость работы запроса.
E>это искусственные данные, и они сильно отличаются от того, что может быть на сервере.
Так слей реальные и прогони, в чем проблема?
E>такое можно писать в RavenDB. такое можно делать и в других базах, хотя работать будет медленнее. E>но что это даст? удобство разработки? так рано или поздно тебе в MS SQL придется делать вьюхи. что будет равносильно созданию индекса в NoSQL базе.
Это даст то что индексированные вьюхи можно написать сильно позже, а в NoSQL ты должен такой дизайн upfront придумать.
E>то есть мы ничего не выигрываем и ничего не теряем.
Еще как выигрываем
E>тем более с учетом того, что 80% данных достаются почти всегда по ключу.
В NoSQL — да, в РСУБД зависит от задачи.
Здравствуйте, Enomay, Вы писали:
G>>Все есть. Читай посты. 10000 — опечатка, там на нолик больше.
G>>Какой там тест меня мало интересует. Для начала пусть какая-нить NoSQL база результат покажет на тех же объемах. Желательно без FTS. FTS и я могу сделать на lucene.
E>где сама задача? можно попробовать сделать синтетический тест.
Это сильно давно было, можешь отмотать ветку назад. Что-то типа поиска статей по тегам, кто-то утверждал что это пипец как медленно будет без FTS.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>Все есть. Читай посты. 10000 — опечатка, там на нолик больше.
ANS>Какие посты? Лень пальцем показать иль нету ничего?
Давно было, я не помню. В древовидном представлении иди вверх по ветке.
ANS>Ты про это? http://data.stackexchange.com/stackoverflow/query/785/how-many-upvotes-do-i-have-for-each-tag
Нет
ANS>btw, Мне написало '28976 rows returned in 6427 ms'. Это нормально? С учем того, что, скорее всего, всё влазит ОЗУ.
Кто и что написало? Если ты про запрос, то у меня при после перезапуска сервера выдает 1-1,5 сек. Далее по 300мсек.
G>>Для начала пусть какая-нить NoSQL база результат покажет на тех же объемах. ANS>Вопрос не ко мне. Но, имхо, ты привратно понимаешь термин NoSql.
Этот вопрос уже был в этой теме. Что такое NoSQL? Ведь оно противопоставляется SQL (РСУБД), которые сейчас умеют и FTS, и xml, и много чего другого.
Здравствуйте, gandjustas, Вы писали:
G>Этот вопрос уже был в этой теме. Что такое NoSQL? Ведь оно противопоставляется SQL (РСУБД), которые сейчас умеют и FTS, и xml, и много чего другого.
SQL — это язык SQL + данные хотя бы в первой НФ + ACID.
NoSQL — отсутствие хотя бы одного из вышеперечисленных свойств (можно можно и без всех трёх ессно).
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>Этот вопрос уже был в этой теме. Что такое NoSQL? Ведь оно противопоставляется SQL (РСУБД), которые сейчас умеют и FTS, и xml, и много чего другого.
ANS>SQL — это язык SQL + данные хотя бы в первой НФ + ACID. ANS>NoSQL — отсутствие хотя бы одного из вышеперечисленных свойств (можно можно и без всех трёх ессно).
Здравствуйте, gandjustas, Вы писали:
G>>>Этот вопрос уже был в этой теме. Что такое NoSQL? Ведь оно противопоставляется SQL (РСУБД), которые сейчас умеют и FTS, и xml, и много чего другого.
ANS>>SQL — это язык SQL + данные хотя бы в первой НФ + ACID. ANS>>NoSQL — отсутствие хотя бы одного из вышеперечисленных свойств (можно можно и без всех трёх ессно).
G>А чем тогда NoSQL лучше, если это отсутствие?
Т.е. к формулировке претензий нет ? Лучше, очевидно, тем, что имеют более другие свойства. И эти другие свойства более важны, чем комбинация из первых трёх.
Здравствуйте, _d_m_, Вы писали:
___>Врут. И врут еще с 2000 версии. Работаем с индексными представлениями еще с 2000 версии. И работало в т.ч. на MSDE.
А это как? Расскажите чуть подробнее. Очень интересно оказалось.
R>>300мс у тебя чистое процессорное время, все данные в кэше, обращений к диску нет вообще G>Так тем более. На реальном серваке это будет не 300, а 30мс или того меньше и ядер будет задействовано побольше.
не будет никакого параллелизма
а) на дешевых запросах параллельный план не генерируется
б) на олтп системах его генерацию отключают
в) если все-таки энфорсить его то пропускная способность запросов упадет раза в 2, ексчендж операторы знаешь ли не бесплатны
G>У меня ни реального железа, ни реального приложения нет. Одно добавление кеша на такие запросы сделает систему в 100 раз быстрее.
что ты кэшировать собрался? резукльтат запросов?
а)выборка 3х тэгов из 100 дает 1млн комбинаций, пусть по 100 записей по 1к каждая — итого 100ГБ опреативки. Выборка по 4м тэгам так вообще никуда не влезет. Можно конечно поприседать вокруг и уменьшить, но порядок цифр уже говорит сам за себя. При росте объемов требования к оперативке сразу вылетят в стратосферу
б)при пропускной способности 30 запросов\сек ты этот кэш еще и набрать-то не сможешь, этот жалкий миллион будет набираться 10 часов с нагрузкой сервера в 100%.
в)при таком времени набора — он устареет раньше чем туда набьется прилично данных. Вообще сомнительно что ты сможешь при таком подходе набрать достаточный надор данных чтобы от кэша был толк
G>Давай лучше ты покажи класс на NoSQL системе. Те же самые условия, такой же запрос. 300 мс ответа и консистентные результаты.
сделаю позже, сейчас запарка на работе
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>>>Этот вопрос уже был в этой теме. Что такое NoSQL? Ведь оно противопоставляется SQL (РСУБД), которые сейчас умеют и FTS, и xml, и много чего другого.
ANS>>>SQL — это язык SQL + данные хотя бы в первой НФ + ACID. ANS>>>NoSQL — отсутствие хотя бы одного из вышеперечисленных свойств (можно можно и без всех трёх ессно).
G>>А чем тогда NoSQL лучше, если это отсутствие?
ANS>Т.е. к формулировке претензий нет ? Лучше, очевидно, тем, что имеют более другие свойства. И эти другие свойства более важны, чем комбинация из первых трёх.
Так вот давай другие свойства, которых в рсубд нету или недостижимы. Описывать NoSQL как отсутствие чего-либо неконструктивно.
Здравствуйте, trophim, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>>Врут. И врут еще с 2000 версии. Работаем с индексными представлениями еще с 2000 версии. И работало в т.ч. на MSDE.
T>А это как? Расскажите чуть подробнее. Очень интересно оказалось.
Use NOEXPAND if you want to be sure to have SQL Server process a query by reading the view itself instead of reading data from the base tables. If for some reason SQL Server chooses a query plan that processes the query against base tables when you'd prefer that it use the view, consider using NOEXPAND. You must use NOEXPAND in all versions of SQL Server other than Developer and Enterprise editions to have SQL Server process a query against an indexed view directly.
E>>ну скажем MySQL справляется. G>Ох не верится. Я вот на ноуте запись в файл без буферизации прогнал, сильно меньше получилось.
over 5k записей в секунду сейчас пишет MySQL. и это еще не предел железа. к тому же, там далеко не ноут стоит
E>>это уже детали реализации. отправив коммент, мы его можем сразу отобразить, но вот дать гарантию того, что он сохранится, не можем. и дело тут не в типа базы данных. E>>а можем и не отображать до тех пор, пока он не переместится во view базу. E>>собственно, придерживаясь Event Sourcing подхода, мы не можем и писать и читать одновременно. что, имхо, есть правильно. G>не понял о чем ты? Вот мы делаем POST, потом GET. А не изменилось состояние, а потом через несколько GET мы получаем результаты. Это противоречит ожиданиям юзеров.
так я же говорил, зависит от интерфейсного решения. от нагрузок. от задач. можно не всегда сразу отправить GET после POST. а ко времени срабатывания GET, данные синхронизируются и станут актуальными.
E>>это искусственные данные, и они сильно отличаются от того, что может быть на сервере. G>Так слей реальные и прогони, в чем проблема?
у меня нет таких данных. есть другие. но и задача там иные.
E>>такое можно писать в RavenDB. такое можно делать и в других базах, хотя работать будет медленнее. E>>но что это даст? удобство разработки? так рано или поздно тебе в MS SQL придется делать вьюхи. что будет равносильно созданию индекса в NoSQL базе. G>Это даст то что индексированные вьюхи можно написать сильно позже, а в NoSQL ты должен такой дизайн upfront придумать.
не считаю это аргументом. сейчас, или потом, писать всё равно придется.
E>>то есть мы ничего не выигрываем и ничего не теряем. G>Еще как выигрываем
это мнимый выигрыш.
E>>тем более с учетом того, что 80% данных достаются почти всегда по ключу. G>В NoSQL — да, в РСУБД зависит от задачи.
не по ключу мы дергаем данные если
а) мы так организовали структуру данных
б) у нас реляционные данные
но в большенстве случаев все же по ключу.
для всего остального есть view. которые отлично работают и в NoSQL
G>>>Для начала пусть какая-нить NoSQL база результат покажет на тех же объемах. ANS>>Вопрос не ко мне. Но, имхо, ты привратно понимаешь термин NoSql. G>Этот вопрос уже был в этой теме. Что такое NoSQL? Ведь оно противопоставляется SQL (РСУБД), которые сейчас умеют и FTS, и xml, и много чего другого.
ну зачем эти глупости? никто никому ничего не противопоставляет. это всего лишь Not Only SQL.
Кстати, SQL всё еще очень плохо умеет xml и FTS. хотя последнее значительно лучше, чем 10 лет назад) но специализированные решения выигрывают.
Здравствуйте, Enomay, Вы писали:
E>>>ну скажем MySQL справляется. G>>Ох не верится. Я вот на ноуте запись в файл без буферизации прогнал, сильно меньше получилось.
E>over 5k записей в секунду сейчас пишет MySQL. и это еще не предел железа. к тому же, там далеко не ноут стоит
Используя Bul Copy в SQL Server можно сильно больше получить, только тут мы теряем ACID. Если в этом цель состоит, то не вижу причин не использовать.
E>так я же говорил, зависит от интерфейсного решения. от нагрузок. от задач. можно не всегда сразу отправить GET после POST.
Почти всегда так и делается.
E>а ко времени срабатывания GET, данные синхронизируются и станут актуальными.
В семантике HTTP заложено что POST изменяет сотояние, а GET — нет. От этого GET можно кешировать. Если момент изменения состояния перемещаешь, то нарушаешь такую логику.
E>>>такое можно писать в RavenDB. такое можно делать и в других базах, хотя работать будет медленнее. E>>>но что это даст? удобство разработки? так рано или поздно тебе в MS SQL придется делать вьюхи. что будет равносильно созданию индекса в NoSQL базе. G>>Это даст то что индексированные вьюхи можно написать сильно позже, а в NoSQL ты должен такой дизайн upfront придумать. E>не считаю это аргументом. сейчас, или потом, писать всё равно придется.
Скорее всего потом не придется. MS SQL на хорошем железе сотни гигабайт держит спокойно, если писать правильно. Даже до таких объемов дорастает малая часть проектов.
E>>>то есть мы ничего не выигрываем и ничего не теряем. G>>Еще как выигрываем E>это мнимый выигрыш.
Это очень реальный выйгрыш в скорости разработки и простоте расширения.
E>>>тем более с учетом того, что 80% данных достаются почти всегда по ключу. G>>В NoSQL — да, в РСУБД зависит от задачи.
E>не по ключу мы дергаем данные если E>а) мы так организовали структуру данных E>б) у нас реляционные данные E>но в большенстве случаев все же по ключу.
В РСУБД у нас реляционные данные
E>для всего остального есть view. которые отлично работают и в NoSQL
View в NoSQL это не View в РСУБД.
Вьюхи в NoSQL базах предварительно вычисляются, это аналогично созданию materialized\indexed view в SQL. Но это уже довольно серьезные оптимизации для SQL, большая часть решается тупо индексами, которые прозрачны для вызывающей стороны. То есть совершенно необязательно создавать индексы заранее.Вполне можно запустить Tuning Adviser, который поработав с реальной нагрузкой расскажет чего надо в базе добавить чтобы быстрее работало.
Здравствуйте, Enomay, Вы писали:
G>>Так вот давай другие свойства, которых в рсубд нету или недостижимы. Описывать NoSQL как отсутствие чего-либо неконструктивно.
E>так ведь везде уже 300 писали E>скорость, масштабируемость, простота и удобство работы, отсутствие четкой схемы документа.
Все это есть в реляционных СУБД.
Кстати проблема определения NoSQL — реальная проблема. Сейчас сложно найти четкое описание, позволяющее классифицировать SQL\NoSQL, а NoSQL решения относят себя к таковым по признакам отсутствия некоторых фич. Как я уже говорил — данная позиция неконструктивна, ибо отсутствие одной фичи не говорит о наличии каких-то других.
Напрмиер тот же RavenDB по юзкейсам не отличается от РСУБД+lucene, а по стабильности работы и скорости ad-hoc запросов второе сильно превосходит первое.
E>>over 5k записей в секунду сейчас пишет MySQL. и это еще не предел железа. к тому же, там далеко не ноут стоит G>Используя Bul Copy в SQL Server можно сильно больше получить, только тут мы теряем ACID. Если в этом цель состоит, то не вижу причин не использовать.
ACID там нафиг не нужен.
в любом случае, MS SQL не тянет. MySQL тянет. любая NoSQL тянет. увы, MS SQL подходит не для всех задач.
E>>так я же говорил, зависит от интерфейсного решения. от нагрузок. от задач. можно не всегда сразу отправить GET после POST. G>Почти всегда так и делается.
где делается? кем делается? тобой? ну ты же не все и не всегда.
E>>а ко времени срабатывания GET, данные синхронизируются и станут актуальными. G>В семантике HTTP заложено что POST изменяет сотояние, а GET — нет. От этого GET можно кешировать. Если момент изменения состояния перемещаешь, то нарушаешь такую логику.
а кто перемещает момент изменения состояния? делаем пост, потом гет. в чем проблема?
E>>не считаю это аргументом. сейчас, или потом, писать всё равно придется. G>Скорее всего потом не придется. MS SQL на хорошем железе сотни гигабайт держит спокойно, если писать правильно. Даже до таких объемов дорастает малая часть проектов.
а у нас не держит. увы.
а если сюда еще добавить огромную посещаемость, то вообще гайки.
E>>это мнимый выигрыш. G>Это очень реальный выйгрыш в скорости разработки и простоте расширения.
ты можешь это для себя утверждать сколько угодно. правдой это не становится.
G>В РСУБД у нас реляционные данные
у вас — да. вы ведь по другому думать не умеете
E>>для всего остального есть view. которые отлично работают и в NoSQL G>View в NoSQL это не View в РСУБД. G>Вьюхи в NoSQL базах предварительно вычисляются, это аналогично созданию materialized\indexed view в SQL. Но это уже довольно серьезные оптимизации для SQL, большая часть решается тупо индексами, которые прозрачны для вызывающей стороны. То есть совершенно необязательно создавать индексы заранее.Вполне можно запустить Tuning Adviser, который поработав с реальной нагрузкой расскажет чего надо в базе добавить чтобы быстрее работало.
то есть, в NoSQL мы создаем VIEW и получаем необходимый результат, тогда как в SQL нам нужно несколько раз к ряду приседать? да ну нафиг такое.
E>>так ведь везде уже 300 писали E>>скорость, масштабируемость, простота и удобство работы, отсутствие четкой схемы документа.
G>Все это есть в реляционных СУБД.
если бы это все было такое хорошее и удобное, люди не выбирали бы для высоконагруженных решений NoSQL.
да и SQL проигрывает по всем параметрам.
G>Напрмиер тот же RavenDB по юзкейсам не отличается от РСУБД+lucene, а по стабильности работы и скорости ad-hoc запросов второе сильно превосходит первое.
Здравствуйте, Enomay, Вы писали:
E>>>over 5k записей в секунду сейчас пишет MySQL. и это еще не предел железа. к тому же, там далеко не ноут стоит G>>Используя Bul Copy в SQL Server можно сильно больше получить, только тут мы теряем ACID. Если в этом цель состоит, то не вижу причин не использовать.
E>ACID там нафиг не нужен.
Ну так используй BulkCopy
E>в любом случае, MS SQL не тянет. MySQL тянет. любая NoSQL тянет. увы, MS SQL подходит не для всех задач.
Это заклинание чтоли? Если ты его не умеешь использовать, то это не значит что не катить. Приведи пример данных и давай забеги проведем MySQL vs SqlServer bulk copy.
E>>>так я же говорил, зависит от интерфейсного решения. от нагрузок. от задач. можно не всегда сразу отправить GET после POST. G>>Почти всегда так и делается.
E>где делается? кем делается? тобой? ну ты же не все и не всегда.
Большинством веб-приложений.
E>>>а ко времени срабатывания GET, данные синхронизируются и станут актуальными. G>>В семантике HTTP заложено что POST изменяет сотояние, а GET — нет. От этого GET можно кешировать. Если момент изменения состояния перемещаешь, то нарушаешь такую логику. E>а кто перемещает момент изменения состояния? делаем пост, потом гет. в чем проблема?
Потому что после post состояние не меняется, оно меняется после.
E>>>не считаю это аргументом. сейчас, или потом, писать всё равно придется. G>>Скорее всего потом не придется. MS SQL на хорошем железе сотни гигабайт держит спокойно, если писать правильно. Даже до таких объемов дорастает малая часть проектов.
E>а у нас не держит. увы.
Значит вы неправильно его используете и все.
E>>>это мнимый выигрыш. G>>Это очень реальный выйгрыш в скорости разработки и простоте расширения. E>ты можешь это для себя утверждать сколько угодно. правдой это не становится.
Ты хочешь сказать что скорость разработки не выйгрыш? Ты в каком мире живешь?
Или может ты покажешь как сделать за 5 минут такой запрос, как я показывал выше? (20 минут вместе с забиванием данных)
G>>В РСУБД у нас реляционные данные E>у вас — да. вы ведь по другому думать не умеете
Не стоит делать таких далекоидущих утверждений Скорее всего это вы не умеете их делать.
E>>>для всего остального есть view. которые отлично работают и в NoSQL G>>View в NoSQL это не View в РСУБД. G>>Вьюхи в NoSQL базах предварительно вычисляются, это аналогично созданию materialized\indexed view в SQL. Но это уже довольно серьезные оптимизации для SQL, большая часть решается тупо индексами, которые прозрачны для вызывающей стороны. То есть совершенно необязательно создавать индексы заранее.Вполне можно запустить Tuning Adviser, который поработав с реальной нагрузкой расскажет чего надо в базе добавить чтобы быстрее работало.
E>то есть, в NoSQL мы создаем VIEW и получаем необходимый результат, тогда как в SQL нам нужно несколько раз к ряду приседать? да ну нафиг такое.
Нет, то что ты называешь View в NoSQL является Materialized\indexed View в SQL. Но производительность в SQL можно поднять вообще не трогая клиентский код, это значит что можно сначала запустить проект, а потом тюнить, а не пытаться оптимальную схему построить с самого начала.
Здравствуйте, Enomay, Вы писали:
E>>>так ведь везде уже 300 писали E>>>скорость, масштабируемость, простота и удобство работы, отсутствие четкой схемы документа.
G>>Все это есть в реляционных СУБД.
E>если бы это все было такое хорошее и удобное, люди не выбирали бы для высоконагруженных решений NoSQL.
Их используют для кеша.
E>да и SQL проигрывает по всем параметрам.
По каким? Покажешь тест?
G>>Напрмиер тот же RavenDB по юзкейсам не отличается от РСУБД+lucene, а по стабильности работы и скорости ad-hoc запросов второе сильно превосходит первое. E>тесты, пруфы. пока это не более чем пустые слова.
Я уже привел тест, в ответ на то что люди утверждали тормознутость работы SQL на таком сценарии, теперь ваша очередь. Возмите свою любимую NoSQL БД и покажите на ней аналогичный функционал, работающий в реальном времени (без асинхронного перевычсления)
E>>ACID там нафиг не нужен. G>Ну так используй BulkCopy E>>в любом случае, MS SQL не тянет. MySQL тянет. любая NoSQL тянет. увы, MS SQL подходит не для всех задач. G>Это заклинание чтоли? Если ты его не умеешь использовать, то это не значит что не катить. Приведи пример данных и давай забеги проведем MySQL vs SqlServer bulk copy.
и как это мне bulk copy поможет при запихивании 5к строк в секунду, при том что каждая запись, это http request? давай, расскажи мне, как ты это будешь делать.
E>>где делается? кем делается? тобой? ну ты же не все и не всегда. G>Большинством веб-приложений.
да что ты?
E>>а кто перемещает момент изменения состояния? делаем пост, потом гет. в чем проблема? G>Потому что после post состояние не меняется, оно меняется после.
предположим, что операция изменения состояния у нас занимает не 1с, а 1 час. у тебя request по таймауту не отвалится?
E>>а у нас не держит. увы. G>Значит вы неправильно его используете и все.
ну конечно, ты, не зная всей специфики "авторитетно" заявляешь. пхэ.
E>>>>это мнимый выигрыш. G>>>Это очень реальный выйгрыш в скорости разработки и простоте расширения. E>>ты можешь это для себя утверждать сколько угодно. правдой это не становится. G>Ты хочешь сказать что скорость разработки не выйгрыш? Ты в каком мире живешь? G>Или может ты покажешь как сделать за 5 минут такой запрос, как я показывал выше? (20 минут вместе с забиванием данных)
иногда потеря времени в начале, может обернуться выигрышем в будущем. ты пытаешься делать утверждения без контекста. что глупо.
G>>>В РСУБД у нас реляционные данные E>>у вас — да. вы ведь по другому думать не умеете G>Не стоит делать таких далекоидущих утверждений Скорее всего это вы не умеете их делать.
просто переставил слова местами. ничего интерестного.
E>>то есть, в NoSQL мы создаем VIEW и получаем необходимый результат, тогда как в SQL нам нужно несколько раз к ряду приседать? да ну нафиг такое. G>Нет, то что ты называешь View в NoSQL является Materialized\indexed View в SQL. Но производительность в SQL можно поднять вообще не трогая клиентский код, это значит что можно сначала запустить проект,
а) view в noSQL к производительности не имеет никакого отношения
б) поднять производительность noSQL решений можно так же не трогая клиентский код. только добавив пару тазиков. очень просто.
G>а потом тюнить, а не пытаться оптимальную схему построить с самого начала.
если у тебя схема кривая, то проблемы будут в любой базе. и в MS SQL в том числе. и тюнингом одним ты не отделаешься.
E>>если бы это все было такое хорошее и удобное, люди не выбирали бы для высоконагруженных решений NoSQL. G>Их используют для кеша.
ложь
E>>да и SQL проигрывает по всем параметрам. G>По каким? Покажешь тест?
в интернете хватает подобного добра.
G>>>Напрмиер тот же RavenDB по юзкейсам не отличается от РСУБД+lucene, а по стабильности работы и скорости ad-hoc запросов второе сильно превосходит первое. E>>тесты, пруфы. пока это не более чем пустые слова. G>Я уже привел тест, в ответ на то что люди утверждали тормознутость работы SQL на таком сценарии, теперь ваша очередь. Возмите свою любимую NoSQL БД и покажите на ней аналогичный функционал, работающий в реальном времени (без асинхронного перевычсления)
не вижу ни тестов, ни утверждений. а значит это остается пустыми словами.
Здравствуйте, Enomay, Вы писали:
E>>>ACID там нафиг не нужен. G>>Ну так используй BulkCopy E>>>в любом случае, MS SQL не тянет. MySQL тянет. любая NoSQL тянет. увы, MS SQL подходит не для всех задач. G>>Это заклинание чтоли? Если ты его не умеешь использовать, то это не значит что не катить. Приведи пример данных и давай забеги проведем MySQL vs SqlServer bulk copy.
E>и как это мне bulk copy поможет при запихивании 5к строк в секунду, при том что каждая запись, это http request? давай, расскажи мне, как ты это будешь делать.
так складывай в буфер, а потом фигач в базу. У тебя все равно acid нету.
E>>>где делается? кем делается? тобой? ну ты же не все и не всегда. G>>Большинством веб-приложений. E>да что ты?
Да-да, сходу найдешь какойнить проект, где не так? (webforms не в счет)
E>>>а кто перемещает момент изменения состояния? делаем пост, потом гет. в чем проблема? G>>Потому что после post состояние не меняется, оно меняется после. E>предположим, что операция изменения состояния у нас занимает не 1с, а 1 час. у тебя request по таймауту не отвалится?
С чего такое предположение? Часто это предположение соотвествует реальности? Скорее всего очень редко. Зачем в этом случае асинхронная обработка?
E>>>а у нас не держит. увы. G>>Значит вы неправильно его используете и все. E>ну конечно, ты, не зная всей специфики "авторитетно" заявляешь. пхэ.
Ну если ты не понимаешь что такое View в SQL.
E>>>>>это мнимый выигрыш. G>>>>Это очень реальный выйгрыш в скорости разработки и простоте расширения. E>>>ты можешь это для себя утверждать сколько угодно. правдой это не становится. G>>Ты хочешь сказать что скорость разработки не выйгрыш? Ты в каком мире живешь? G>>Или может ты покажешь как сделать за 5 минут такой запрос, как я показывал выше? (20 минут вместе с забиванием данных) E>иногда потеря времени в начале, может обернуться выигрышем в будущем. ты пытаешься делать утверждения без контекста. что глупо.
Это скорее ложь чем правда, история полна обратных примеров, когда попытка предусмотреть развите системы оборачивается дальнейшей переделкой архитектуры, тогда как изначально простое решение, потом вполне нормально расширяется:
1)twitter
2)facebook
3)stackoverflow
4)livejournal
именно так и делались, подробности можешь на хайлоде прочитать.
E>если у тебя схема кривая, то проблемы будут в любой базе. и в MS SQL в том числе. и тюнингом одним ты не отделаешься.
В SQL некривая схема обеспечивается нормализацией, а для noSQL есть критерии некривой схемы?
Я вот постил пример: stackoverflow. юзеры, посты, коменты, оценки, теги, юзкейсы можно на сайте посмотреть. Как сделать "некривую" схему на NoSQL?
Здравствуйте, Enomay, Вы писали:
E>>>если бы это все было такое хорошее и удобное, люди не выбирали бы для высоконагруженных решений NoSQL. G>>Их используют для кеша.
E>ложь
Да ну? Stackoverflow использует redis для кеша, facebook тоже использует для кеширования и оптимизации cassandra кажись. В любом случае за ними стоят нормальные sql-acid-субд.
Единственный только твиттер не использует, потому что у него количество записей в единицу времени просто заоблачное.
E>>>да и SQL проигрывает по всем параметрам. G>>По каким? Покажешь тест? E>в интернете хватает подобного добра.
Ссылку дай, разговоров в интернете полно, а результатов забегов нет. Я тут проводил забеги, SQL вполне нормальные результаты показывает и нету смысла использовать что-то еще пока нагрузка не возросла.
G>>>>Напрмиер тот же RavenDB по юзкейсам не отличается от РСУБД+lucene, а по стабильности работы и скорости ad-hoc запросов второе сильно превосходит первое. E>>>тесты, пруфы. пока это не более чем пустые слова. G>>Я уже привел тест, в ответ на то что люди утверждали тормознутость работы SQL на таком сценарии, теперь ваша очередь. Возмите свою любимую NoSQL БД и покажите на ней аналогичный функционал, работающий в реальном времени (без асинхронного перевычсления)
E>не вижу ни тестов, ни утверждений. а значит это остается пустыми словами.
Ты тему читаешь вообще?
Давай ты сначала прочитаешь сначала, а потом будешь писать, ок?
E>>и как это мне bulk copy поможет при запихивании 5к строк в секунду, при том что каждая запись, это http request? давай, расскажи мне, как ты это будешь делать. G>так складывай в буфер, а потом фигач в базу. У тебя все равно acid нету.
нафига козе боян если есть другие работающие без бубна решения?
то ты кричишь везде что слой кеширования нафиг не нужен, ибо сиквел рвет всех, то предлагаешь доп. слой.
E>>>>где делается? кем делается? тобой? ну ты же не все и не всегда. G>>>Большинством веб-приложений. E>>да что ты? G>Да-да, сходу найдешь какойнить проект, где не так? (webforms не в счет)
соц. сети посмотри. другие интерактивные сайты с высокой нагрузкой.
E>>предположим, что операция изменения состояния у нас занимает не 1с, а 1 час. у тебя request по таймауту не отвалится? G>С чего такое предположение? Часто это предположение соотвествует реальности? Скорее всего очень редко. Зачем в этом случае асинхронная обработка?
это у тебя редко. ты опять говоришь за всех.
E>>иногда потеря времени в начале, может обернуться выигрышем в будущем. ты пытаешься делать утверждения без контекста. что глупо. G>Это скорее ложь чем правда, история полна обратных примеров, когда попытка предусмотреть развите системы оборачивается дальнейшей переделкой архитектуры, тогда как изначально простое решение, потом вполне нормально расширяется: G>1)twitter G>2)facebook G>3)stackoverflow G>4)livejournal G>именно так и делались, подробности можешь на хайлоде прочитать.
заметь, там нигде нет ни sql, ни view
E>>если у тебя схема кривая, то проблемы будут в любой базе. и в MS SQL в том числе. и тюнингом одним ты не отделаешься. G>В SQL некривая схема обеспечивается нормализацией, а для noSQL есть критерии некривой схемы?
нормализация уменьшает производительность.
опять же, ты не учитываешь разных человеческих факторов, которые в сиквеле всё это дело сломают. это ты над своими проектами сам трудишься. а у других иначе.
G>Я вот постил пример: stackoverflow. юзеры, посты, коменты, оценки, теги, юзкейсы можно на сайте посмотреть. Как сделать "некривую" схему на NoSQL?
это очень абстрактное задание.
можешь написать на c# объектную модель под это дело. такое, исходя из твоего условия, она и будет.
G>>>Их используют для кеша. E>>ложь G>Да ну? Stackoverflow использует redis для кеша, facebook тоже использует для кеширования и оптимизации cassandra кажись. В любом случае за ними стоят нормальные sql-acid-субд.
читай архитектуры соц. сетей. там везде сиквел как view база.
G>Единственный только твиттер не использует, потому что у него количество записей в единицу времени просто заоблачное.
E>>>>да и SQL проигрывает по всем параметрам. G>>>По каким? Покажешь тест? E>>в интернете хватает подобного добра. G>Ссылку дай, разговоров в интернете полно, а результатов забегов нет. Я тут проводил забеги, SQL вполне нормальные результаты показывает и нету смысла использовать что-то еще пока нагрузка не возросла.
так нет требований четких. а значит нет четкого решения.
G>>>>>Напрмиер тот же RavenDB по юзкейсам не отличается от РСУБД+lucene, а по стабильности работы и скорости ad-hoc запросов второе сильно превосходит первое. E>>>>тесты, пруфы. пока это не более чем пустые слова. G>>>Я уже привел тест, в ответ на то что люди утверждали тормознутость работы SQL на таком сценарии, теперь ваша очередь. Возмите свою любимую NoSQL БД и покажите на ней аналогичный функционал, работающий в реальном времени (без асинхронного перевычсления)
E>>не вижу ни тестов, ни утверждений. а значит это остается пустыми словами. G> G>Ты тему читаешь вообще? G>Давай ты сначала прочитаешь сначала, а потом будешь писать, ок?
Ссылку дай, разговоров в интернете полно, а результатов забегов нет. (c) gandjustas
Здравствуйте, Enomay, Вы писали:
E>>>и как это мне bulk copy поможет при запихивании 5к строк в секунду, при том что каждая запись, это http request? давай, расскажи мне, как ты это будешь делать. G>>так складывай в буфер, а потом фигач в базу. У тебя все равно acid нету.
E>нафига козе боян если есть другие работающие без бубна решения? E>то ты кричишь везде что слой кеширования нафиг не нужен, ибо сиквел рвет всех, то предлагаешь доп. слой.
Я говорю что заранее создавать кеширование не надо. Надо создавать по мере необходимости.
Многие пропагандируют подход: вот мы делаем абы-как, все равно потом все будем кешировать. Я предлагаю подумать на этапе проектирования схемы данных и не опираться на то что кеш всегда поможет (ибо обычно он не помогает в таких случаях).
E>>>>>где делается? кем делается? тобой? ну ты же не все и не всегда. G>>>>Большинством веб-приложений. E>>>да что ты? G>>Да-да, сходу найдешь какойнить проект, где не так? (webforms не в счет)
E>соц. сети посмотри. другие интерактивные сайты с высокой нагрузкой.
Да, они делают тоже самое, но с ajax.
E>>>предположим, что операция изменения состояния у нас занимает не 1с, а 1 час. у тебя request по таймауту не отвалится? G>>С чего такое предположение? Часто это предположение соотвествует реальности? Скорее всего очень редко. Зачем в этом случае асинхронная обработка? E>это у тебя редко. ты опять говоришь за всех.
А ты сайты посмотри, какие дейтсвия пользователя могут приводить к обработке часами? Добавление постов в форум? Выставление оценок? Навигация по страницам? Покупка в интернет-магазине?
E>>>иногда потеря времени в начале, может обернуться выигрышем в будущем. ты пытаешься делать утверждения без контекста. что глупо. G>>Это скорее ложь чем правда, история полна обратных примеров, когда попытка предусмотреть развите системы оборачивается дальнейшей переделкой архитектуры, тогда как изначально простое решение, потом вполне нормально расширяется: G>>1)twitter G>>2)facebook G>>3)stackoverflow G>>4)livejournal G>>именно так и делались, подробности можешь на хайлоде прочитать.
E>заметь, там нигде нет ни sql, ни view
Там везде есть SQL, кроме твиттера.
E>>>если у тебя схема кривая, то проблемы будут в любой базе. и в MS SQL в том числе. и тюнингом одним ты не отделаешься. G>>В SQL некривая схема обеспечивается нормализацией, а для noSQL есть критерии некривой схемы?
E>нормализация уменьшает производительность.
Что за глупая мантра?
E>опять же, ты не учитываешь разных человеческих факторов, которые в сиквеле всё это дело сломают. это ты над своими проектами сам трудишься. а у других иначе.
А думаешь человеческие факторы завият от технологий? Накосячить можно везде.
G>>Я вот постил пример: stackoverflow. юзеры, посты, коменты, оценки, теги, юзкейсы можно на сайте посмотреть. Как сделать "некривую" схему на NoSQL?
E>это очень абстрактное задание.
Это очень реальное задание и есть примеры кода, можешь посмотреть.
E>можешь написать на c# объектную модель под это дело. такое, исходя из твоего условия, она и будет.
Да любая модель, хоть тупо {Id, Title} для каждого элемента + связи, остальное на твое усмотрение.
Здравствуйте, Enomay, Вы писали:
G>>>>Их используют для кеша. E>>>ложь G>>Да ну? Stackoverflow использует redis для кеша, facebook тоже использует для кеширования и оптимизации cassandra кажись. В любом случае за ними стоят нормальные sql-acid-субд.
E>читай архитектуры соц. сетей. там везде сиквел как view база.
Нет, там она как durable storage, кеши обновляются из БД. Кеши вторичны по отношению к БД.
G>>Ссылку дай, разговоров в интернете полно, а результатов забегов нет. Я тут проводил забеги, SQL вполне нормальные результаты показывает и нету смысла использовать что-то еще пока нагрузка не возросла. E>так нет требований четких. а значит нет четкого решения.
Ну хотябы на примиер сравнения. Я вижу преимущества NoSQL только на словах, наделе их нет. Если почитать посты с дефирамбами то выясняется что SQL решение не заработало потому что разработчики тупо не знали SQL и не умели делать базы.
E>>нафига козе боян если есть другие работающие без бубна решения? E>>то ты кричишь везде что слой кеширования нафиг не нужен, ибо сиквел рвет всех, то предлагаешь доп. слой. G>Я говорю что заранее создавать кеширование не надо. Надо создавать по мере необходимости. G>Многие пропагандируют подход: вот мы делаем абы-как, все равно потом все будем кешировать. Я предлагаю подумать на этапе проектирования схемы данных и не опираться на то что кеш всегда поможет (ибо обычно он не помогает в таких случаях).
для стартапов это отличный подход. они как правило имеют высокую нагрузку, если взлетают. либо не взлетают. там это более чем оправдано.
E>>соц. сети посмотри. другие интерактивные сайты с высокой нагрузкой. G>Да, они делают тоже самое, но с ajax.
они делают пост комента, но они не загружают их все после этого.
E>>>>предположим, что операция изменения состояния у нас занимает не 1с, а 1 час. у тебя request по таймауту не отвалится? G>>>С чего такое предположение? Часто это предположение соотвествует реальности? Скорее всего очень редко. Зачем в этом случае асинхронная обработка? E>>это у тебя редко. ты опять говоришь за всех. G>А ты сайты посмотри, какие дейтсвия пользователя могут приводить к обработке часами? Добавление постов в форум? Выставление оценок? Навигация по страницам? Покупка в интернет-магазине?
я не пишу интернет-магазинов. последние 7 лет я разрабатываю тяжелые корпоративные приложения. там много операций могут длиться минутами.
E>>заметь, там нигде нет ни sql, ни view G>Там везде есть SQL, кроме твиттера.
в доску денормализованный, конечно есть.
E>>нормализация уменьшает производительность. G>Что за глупая мантра?
это не мантра. это реальность. не зря же все используют денормализацию в высоконагруженных системах.
E>>опять же, ты не учитываешь разных человеческих факторов, которые в сиквеле всё это дело сломают. это ты над своими проектами сам трудишься. а у других иначе. G>А думаешь человеческие факторы завият от технологий? Накосячить можно везде.
да, но подпортить план в сиквеле куда проще.
G>>>Я вот постил пример: stackoverflow. юзеры, посты, коменты, оценки, теги, юзкейсы можно на сайте посмотреть. Как сделать "некривую" схему на NoSQL? E>>это очень абстрактное задание. G>Это очень реальное задание и есть примеры кода, можешь посмотреть.
твоё реально задание ограничивается перечислением сущностей.
E>>можешь написать на c# объектную модель под это дело. такое, исходя из твоего условия, она и будет. G>Да любая модель, хоть тупо {Id, Title} для каждого элемента + связи, остальное на твое усмотрение.
E>>читай архитектуры соц. сетей. там везде сиквел как view база. G>Нет, там она как durable storage, кеши обновляются из БД. Кеши вторичны по отношению к БД.
пруф.
G>>>Ссылку дай, разговоров в интернете полно, а результатов забегов нет. Я тут проводил забеги, SQL вполне нормальные результаты показывает и нету смысла использовать что-то еще пока нагрузка не возросла. E>>так нет требований четких. а значит нет четкого решения. G>Ну хотябы на примиер сравнения. Я вижу преимущества NoSQL только на словах, наделе их нет. Если почитать посты с дефирамбами то выясняется что SQL решение не заработало потому что разработчики тупо не знали SQL и не умели делать базы.
нууу
возьми фотогалерею с голосованиями.
с NoSQL мы можем сразу приступить к разработке, по мере необходимости дополняя и расширяя модель. мы это делаем совершенно ни о чем не заботясь.
ни о 3х нормальных формах, ни о индексах, ни о красивых планах.
по мере роста нагрузки, мы будем добавлять сервера.
всё. быстро, просто, масштабируемо. а главное дешево.
всё это отлично ложится на NoSQL. 80% операций — доставание данных по ключу. 20% — view через map/reduce.
Здравствуйте, Enomay, Вы писали:
E>>>нафига козе боян если есть другие работающие без бубна решения? E>>>то ты кричишь везде что слой кеширования нафиг не нужен, ибо сиквел рвет всех, то предлагаешь доп. слой. G>>Я говорю что заранее создавать кеширование не надо. Надо создавать по мере необходимости. G>>Многие пропагандируют подход: вот мы делаем абы-как, все равно потом все будем кешировать. Я предлагаю подумать на этапе проектирования схемы данных и не опираться на то что кеш всегда поможет (ибо обычно он не помогает в таких случаях).
E>для стартапов это отличный подход. они как правило имеют высокую нагрузку, если взлетают. либо не взлетают. там это более чем оправдано.
Ты о чем? У стартапов нагрузки нет. Когда она появляется начинает обычно жопа, все висит, кеширование не помогает. Чтобы проблемы исправить — надо перефигачить все решение с нуля. И вот там уже NoSQL если знаний SQL не хватает. А если знаний SQL хватает, то работают годами и кучей пользователей, а потом ставят redis для кеша и luncene для поиска (stackoverflow).
E>>>соц. сети посмотри. другие интерактивные сайты с высокой нагрузкой. G>>Да, они делают тоже самое, но с ajax. E>они делают пост комента, но они не загружают их все после этого.
Это если POST возвращает результат, а если после POST результат неизвестен, то можно только пинать GET и молиться что на какомнить прокси не включено агрессивное кеширование.
E>>>>>предположим, что операция изменения состояния у нас занимает не 1с, а 1 час. у тебя request по таймауту не отвалится? G>>>>С чего такое предположение? Часто это предположение соотвествует реальности? Скорее всего очень редко. Зачем в этом случае асинхронная обработка? E>>>это у тебя редко. ты опять говоришь за всех. G>>А ты сайты посмотри, какие дейтсвия пользователя могут приводить к обработке часами? Добавление постов в форум? Выставление оценок? Навигация по страницам? Покупка в интернет-магазине?
E>я не пишу интернет-магазинов. последние 7 лет я разрабатываю тяжелые корпоративные приложения. там много операций могут длиться минутами.
Напрмиер? Какое действие пользователя приводит к операции изменению состояния, которое длится минутами?
E>>>нормализация уменьшает производительность. G>>Что за глупая мантра?
E>это не мантра. это реальность. не зря же все используют денормализацию в высоконагруженных системах.
Это и есть глупая мантра. Ты не понимаешь причин почему люди так делают.
E>>>опять же, ты не учитываешь разных человеческих факторов, которые в сиквеле всё это дело сломают. это ты над своими проектами сам трудишься. а у других иначе. G>>А думаешь человеческие факторы завият от технологий? Накосячить можно везде. E>да, но подпортить план в сиквеле куда проще.
Главное что его проще подправить, зачастую без правки самого запроса.
G>>>>Я вот постил пример: stackoverflow. юзеры, посты, коменты, оценки, теги, юзкейсы можно на сайте посмотреть. Как сделать "некривую" схему на NoSQL? E>>>это очень абстрактное задание. G>>Это очень реальное задание и есть примеры кода, можешь посмотреть. E>твоё реально задание ограничивается перечислением сущностей.
Ns stackowerflow не видел?
E>>>можешь написать на c# объектную модель под это дело. такое, исходя из твоего условия, она и будет. G>>Да любая модель, хоть тупо {Id, Title} для каждого элемента + связи, остальное на твое усмотрение. E>что любая модель?
Кейсы посмотри на реальном сайте stackoverflow.
Здравствуйте, Enomay, Вы писали:
E>>>читай архитектуры соц. сетей. там везде сиквел как view база. G>>Нет, там она как durable storage, кеши обновляются из БД. Кеши вторичны по отношению к БД.
E>пруф.
http://tokarchuk.ru/2010/07/%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0-%D0%B1%D0%BE%D0%BB%D1%8C%D1%88%D0%B8%D1%85-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2-facebook/
G>>>>Ссылку дай, разговоров в интернете полно, а результатов забегов нет. Я тут проводил забеги, SQL вполне нормальные результаты показывает и нету смысла использовать что-то еще пока нагрузка не возросла. E>>>так нет требований четких. а значит нет четкого решения. G>>Ну хотябы на примиер сравнения. Я вижу преимущества NoSQL только на словах, наделе их нет. Если почитать посты с дефирамбами то выясняется что SQL решение не заработало потому что разработчики тупо не знали SQL и не умели делать базы.
E>нууу E>возьми фотогалерею с голосованиями. E>с NoSQL мы можем сразу приступить к разработке, по мере необходимости дополняя и расширяя модель. мы это делаем совершенно ни о чем не заботясь.
А c SQL нельзя чтоли? CodeFirst есть, automatic migrations есть.
Я вот так и сделал про статьи с тегами. Потом SQL писал чтобы заполнить.
E>ни о 3х нормальных формах, ни о индексах, ни о красивых планах. E>по мере роста нагрузки, мы будем добавлять сервера. E>всё. быстро, просто, масштабируемо. а главное дешево. E>всё это отлично ложится на NoSQL. 80% операций — доставание данных по ключу. 20% — view через map/reduce.
Отлично, покажи простое решение: есть те авторы 1-* статьи(фото) *-* теги, везде связи много-ко многим.
Нужно:
1)галерея по автору
2)Статьи(Фотки) по тегам (в том числе многим тегам)
3)Статьи(Фотки) по дате добавления
1000 пользоветелй, 100000 статей (фоток), 100 тегов. Связей статей(Фоток) к тегам — 1000000.
Интерфейс не нужен, нужно просто консольное приложение чтобы забеги проводить.
Кстати в SQL ни одного indexed view для этого не нужно.
E>>для стартапов это отличный подход. они как правило имеют высокую нагрузку, если взлетают. либо не взлетают. там это более чем оправдано. G>Ты о чем? У стартапов нагрузки нет. Когда она появляется начинает обычно жопа, все висит, кеширование не помогает. Чтобы проблемы исправить — надо перефигачить все решение с нуля. И вот там уже NoSQL если знаний SQL не хватает. А если знаний SQL хватает, то работают годами и кучей пользователей, а потом ставят redis для кеша и luncene для поиска (stackoverflow).
ох мечты и фантазии одни.
особенно базы, которые годами работают с кучей пользователей...
E>>>>соц. сети посмотри. другие интерактивные сайты с высокой нагрузкой. G>>>Да, они делают тоже самое, но с ajax. E>>они делают пост комента, но они не загружают их все после этого. G>Это если POST возвращает результат, а если после POST результат неизвестен, то можно только пинать GET и молиться что на какомнить прокси не включено агрессивное кеширование.
после отправки сообщения, оно рисуется в HTML и делается POST. какой GET? ты о чем?
E>>я не пишу интернет-магазинов. последние 7 лет я разрабатываю тяжелые корпоративные приложения. там много операций могут длиться минутами. G>Напрмиер? Какое действие пользователя приводит к операции изменению состояния, которое длится минутами?
например построение отчета за большой промежуток времени. некоторые отчеты строятся часами и выполняются ночью.
E>>>>нормализация уменьшает производительность. G>>>Что за глупая мантра?
E>>это не мантра. это реальность. не зря же все используют денормализацию в высоконагруженных системах. G> G>Это и есть глупая мантра. Ты не понимаешь причин почему люди так делают.
ну давай, расскажи для чего это делают.
E>>>>опять же, ты не учитываешь разных человеческих факторов, которые в сиквеле всё это дело сломают. это ты над своими проектами сам трудишься. а у других иначе. G>>>А думаешь человеческие факторы завият от технологий? Накосячить можно везде. E>>да, но подпортить план в сиквеле куда проще. G>Главное что его проще подправить, зачастую без правки самого запроса.
ну расскажи мне как подправить план запроса с 6 left outer join'ами.
G>Ns stackowerflow не видел? G>Кейсы посмотри на реальном сайте stackoverflow.
ну ты же понимаешь что никто для тебя не станет писать stackoverflow 2.
Здравствуйте, Enomay, Вы писали:
E>>>для стартапов это отличный подход. они как правило имеют высокую нагрузку, если взлетают. либо не взлетают. там это более чем оправдано. G>>Ты о чем? У стартапов нагрузки нет. Когда она появляется начинает обычно жопа, все висит, кеширование не помогает. Чтобы проблемы исправить — надо перефигачить все решение с нуля. И вот там уже NoSQL если знаний SQL не хватает. А если знаний SQL хватает, то работают годами и кучей пользователей, а потом ставят redis для кеша и luncene для поиска (stackoverflow).
E>ох мечты и фантазии одни. E>особенно базы, которые годами работают с кучей пользователей...
Это факты, почитай про stackoverflow.
E>>>>>соц. сети посмотри. другие интерактивные сайты с высокой нагрузкой. G>>>>Да, они делают тоже самое, но с ajax. E>>>они делают пост комента, но они не загружают их все после этого. G>>Это если POST возвращает результат, а если после POST результат неизвестен, то можно только пинать GET и молиться что на какомнить прокси не включено агрессивное кеширование.
E>после отправки сообщения, оно рисуется в HTML и делается POST. какой GET? ты о чем?
А если не добавится пост? Человек сделает GET и что увидит?
В нормальных интерфейсах что-то рисуется после того как POST вернет ответ и на этот момент гарантировано данные попали в базу. То есть после f5 пользователь увидит тоже самое, если других изменений не было. Если после POST данные не попадают в базу стразу, то ты никак не сделаешь согласованное поведение.
E>>>я не пишу интернет-магазинов. последние 7 лет я разрабатываю тяжелые корпоративные приложения. там много операций могут длиться минутами. G>>Напрмиер? Какое действие пользователя приводит к операции изменению состояния, которое длится минутами? E>например построение отчета за большой промежуток времени. некоторые отчеты строятся часами и выполняются ночью.
И ты мне говорил про асинхронность? А OLAP использовать не? Кроме того читай тут
: оборот за любой период за доли секунды в реальном времени (я на 10000000 проводок проверял).
E>>>>>нормализация уменьшает производительность. G>>>>Что за глупая мантра?
E>>>это не мантра. это реальность. не зря же все используют денормализацию в высоконагруженных системах. G>> G>>Это и есть глупая мантра. Ты не понимаешь причин почему люди так делают.
E>ну давай, расскажи для чего это делают.
Нет, давай ты сам вопрос изучишь, перед тем как ты говорить будешь. Если хочешь, приходи на курс по оптимизации запросов. Много нового узнаешь.
E>>>>>опять же, ты не учитываешь разных человеческих факторов, которые в сиквеле всё это дело сломают. это ты над своими проектами сам трудишься. а у других иначе. G>>>>А думаешь человеческие факторы завият от технологий? Накосячить можно везде. E>>>да, но подпортить план в сиквеле куда проще. G>>Главное что его проще подправить, зачастую без правки самого запроса.
E> E>ну расскажи мне как подправить план запроса с 6 left outer join'ами.
Тут уже лучше сам запрос править. Хотя если приведешь данные и запрос, то можно подумать.
G>>Ns stackowerflow не видел? G>>Кейсы посмотри на реальном сайте stackoverflow.
E>ну ты же понимаешь что никто для тебя не станет писать stackoverflow 2.
А не не нужен он, мне нужна только схема данных, которая эффективно реализует сценарии.
Вот для RavenDB есть такое, но там очень мощные механизмы, которых в других NoSQL нету, да и глючит это все.
Здравствуйте, Enomay, Вы писали:
E>предположим, что операция изменения состояния у нас занимает не 1с, а 1 час. у тебя request по таймауту не отвалится?
Ну здесь уже не надо предположений — если руки из ж... растут, то час выполняется.
G>Давай лучше ты покажи класс на NoSQL системе. Те же самые условия, такой же запрос. 300 мс ответа и консистентные результаты.
пока попробовал db4o(versant) — epic fail, 2сек
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, Enomay, Вы писали:
E>>например построение отчета за большой промежуток времени. некоторые отчеты строятся часами и выполняются ночью.
___>Понятно. Достаточно. Дальше больше продолжать не следует.
всегда радовали чуваки, с крутыми нетормозящими базами, указывающие всем на кривые руки, даже не зная сути.
для непонятливых. у нас добавляется ~20k записей в секунду. ночью меньше.
не сложно подсчитать сколько записей собирается за день. неделю. месяц. год.
у нас базе 10 лет. по этим данным нужно строить отчеты.
у тебя физически пропускной способности дисковой подсистемы не хватит что бы перелопатить такую гору данных.
Здравствуйте, Enomay, Вы писали:
E>всегда радовали чуваки, с крутыми нетормозящими базами, указывающие всем на кривые руки, даже не зная сути.
E>для непонятливых. у нас добавляется ~20k записей в секунду. ночью меньше. E>не сложно подсчитать сколько записей собирается за день. неделю. месяц. год. E>у нас базе 10 лет. по этим данным нужно строить отчеты. E>у тебя физически пропускной способности дисковой подсистемы не хватит что бы перелопатить такую гору данных.
Получается меньше 600 Гб в год. Я бы не сказал, что это сверхобъемы для базы данных. Хотя, разумеется, при таких объемах требуются взвешенные решения и тщательный подход в решению задач. Например, реализация механизмов, не требующих лопатить все данные за 10 лет на OLTP базе.
Но лично я не вижу, как тут может помочь NoSQL. И я лично не вижу тут тех объемов, от которых современные СУБД должны падать в обморок.
Здравствуйте, Enomay, Вы писали:
E>Здравствуйте, _d_m_, Вы писали:
___>>Здравствуйте, Enomay, Вы писали:
E>>>например построение отчета за большой промежуток времени. некоторые отчеты строятся часами и выполняются ночью.
___>>Понятно. Достаточно. Дальше больше продолжать не следует.
E>всегда радовали чуваки, с крутыми нетормозящими базами, указывающие всем на кривые руки, даже не зная сути.
E>для непонятливых. у нас добавляется ~20k записей в секунду. ночью меньше. E>не сложно подсчитать сколько записей собирается за день. неделю. месяц. год. E>у нас базе 10 лет. по этим данным нужно строить отчеты. E>у тебя физически пропускной способности дисковой подсистемы не хватит что бы перелопатить такую гору данных.
Ты все еще бравируешь своим незнанием. Используй OLAP, он как раз на решение таких задач заточен.
ЗЫ. Чем тут поможет NoSQL? По ним отчеты быстрее строятся?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>конфигурируемых пользователями формами, и real-time оповещенияим. G>>А тут NoSQL причем? Как это вообще с системами хранения связано? C>А ты подумай.
никак не связано.
NoSQL нипричем и нафиг для этих фич не нужен
если быть точным — "конфигурируемых пользователями формами" — вопрос весьма спорный
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Аноним, Вы писали:
>> G>Интересно будет посмотреть куда оно все пойдет когда SSD массово войдут на рынок. >> Да
AB>Результат уже известен — профита почти нет, а цена как у самолета — революции не случится.
профит огромный (это из собственного опыта — два месяца назад купил таки)
произвольный доступ заруливает в минуса магнитные винты
Всё сказанное выше — личное мнение, если не указано обратное.
_AB>Получается меньше 600 Гб в год. Я бы не сказал, что это сверхобъемы для базы данных. Хотя, разумеется, при таких объемах требуются взвешенные решения и тщательный подход в решению задач. Например, реализация механизмов, не требующих лопатить все данные за 10 лет на OLTP базе.
Поправка: 600 миллиардов строк в год. Плюс каждая строка весит пускай байт по 100 (для ровного счета). Получаем 63 терабайта. Совсем другой порядок, не так ли?
G>Ты все еще бравируешь своим незнанием. Используй OLAP, он как раз на решение таких задач заточен.
ты все еще бравируешь своей глупостью, делая заявление совершенно не зная какого рода данные там лежат, и почему OLAP на них не работает.
прочем, как всегда.
G>ЗЫ. Чем тут поможет NoSQL? По ним отчеты быстрее строятся?
Здравствуйте, Enomay, Вы писали:
G>>Ты все еще бравируешь своим незнанием. Используй OLAP, он как раз на решение таких задач заточен.
E>ты все еще бравируешь своей глупостью, делая заявление совершенно не зная какого рода данные там лежат, и почему OLAP на них не работает. E>прочем, как всегда.
Ты поосторожее со словами. Ты сам не говоришь что за данные, при этом говоришь мне о глупости.
Ты не сказал почему OLAP не подошел. Значит причин этому не было.
Уверен что данные там лежат самые обычные — строки, числа, даты.
G>>ЗЫ. Чем тут поможет NoSQL? По ним отчеты быстрее строятся? E>а кто сказал что NoSQL тут поможет?
Ты, будешь оправдываться?
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, Enomay, Вы писали:
E>>предположим, что операция изменения состояния у нас занимает не 1с, а 1 час. у тебя request по таймауту не отвалится?
___>Ну здесь уже не надо предположений — если руки из ж... растут, то час выполняется.
предположим — действие — аплоад видео ролика. результат — транскодированное видео в другой формат.
ну давай, дядя с прямыми руками. расскажи откуда должны руки рости, что бы ответ с необходимым результатом пользователь получил в течении хотя бы 1й минуты.
E>>ты все еще бравируешь своей глупостью, делая заявление совершенно не зная какого рода данные там лежат, и почему OLAP на них не работает. E>>прочем, как всегда. G>Ты поосторожее со словами. Ты сам не говоришь что за данные, при этом говоришь мне о глупости.
прежде чем указывать другим, научись быть осторожнее сам.
G>Ты не сказал почему OLAP не подошел. Значит причин этому не было. G>Уверен что данные там лежат самые обычные — строки, числа, даты.
рад за твою уверенность, мр. всезнайка.
а отчеты тоже самые обычные — графики, таблицы.
но OLAP не подходит
G>>>ЗЫ. Чем тут поможет NoSQL? По ним отчеты быстрее строятся? E>>а кто сказал что NoSQL тут поможет? G>Ты, будешь оправдываться?
Здравствуйте, Enomay, Вы писали:
G>>Ты не сказал почему OLAP не подошел. Значит причин этому не было. G>>Уверен что данные там лежат самые обычные — строки, числа, даты.
E>рад за твою уверенность, мр. всезнайка. E>а отчеты тоже самые обычные — графики, таблицы. E>но OLAP не подходит
Так напиши почему не подходит.
Что же за данные такие, которые нельзя olap_у скормить?
G>>>>ЗЫ. Чем тут поможет NoSQL? По ним отчеты быстрее строятся? E>>>а кто сказал что NoSQL тут поможет? G>>Ты, будешь оправдываться?
E>пруф.
G>>>Ты не сказал почему OLAP не подошел. Значит причин этому не было. G>>>Уверен что данные там лежат самые обычные — строки, числа, даты. E>>рад за твою уверенность, мр. всезнайка. E>>а отчеты тоже самые обычные — графики, таблицы. E>>но OLAP не подходит G>Так напиши почему не подходит. G>Что же за данные такие, которые нельзя olap_у скормить?
дело не в данных, а в специфике самих отчётов.
G>>>>>ЗЫ. Чем тут поможет NoSQL? По ним отчеты быстрее строятся? E>>>>а кто сказал что NoSQL тут поможет? G>>>Ты, будешь оправдываться?
E>>пруф. G>Твои посты вверх по ветке.
пруф где я сказал что NoSQL лучше подходит для построения отчетов, или балабол.
Здравствуйте, Enomay, Вы писали:
G>>>>Ты не сказал почему OLAP не подошел. Значит причин этому не было. G>>>>Уверен что данные там лежат самые обычные — строки, числа, даты. E>>>рад за твою уверенность, мр. всезнайка. E>>>а отчеты тоже самые обычные — графики, таблицы. E>>>но OLAP не подходит G>>Так напиши почему не подходит. G>>Что же за данные такие, которые нельзя olap_у скормить?
E>дело не в данных, а в специфике самих отчётов.
Ок, что за специфика. Опиши так чтобы другие поняли.
G>>>>>>ЗЫ. Чем тут поможет NoSQL? По ним отчеты быстрее строятся? E>>>>>а кто сказал что NoSQL тут поможет? G>>>>Ты, будешь оправдываться?
E>>>пруф. G>>Твои посты вверх по ветке.
E>пруф где я сказал что NoSQL лучше подходит для построения отчетов, или балабол.
Ты утверждал что NoSQL лучше подходит при большом количестве записей. Покачто ты доказываешь обратное.
E>>дело не в данных, а в специфике самих отчётов. G>Ок, что за специфика. Опиши так чтобы другие поняли.
внутренняя специфика, договор о не разглашении и все такое прочее.
G>>>>>>>ЗЫ. Чем тут поможет NoSQL? По ним отчеты быстрее строятся? E>>>>>>а кто сказал что NoSQL тут поможет? G>>>>>Ты, будешь оправдываться? E>>пруф где я сказал что NoSQL лучше подходит для построения отчетов, или балабол. G>Ты утверждал что NoSQL лучше подходит при большом количестве записей. Покачто ты доказываешь обратное.
Здравствуйте, Enomay, Вы писали:
E>>>дело не в данных, а в специфике самих отчётов. G>>Ок, что за специфика. Опиши так чтобы другие поняли.
E>внутренняя специфика, договор о не разглашении и все такое прочее.
Ага, конечно. Слив засчитан.
G>>>>>>>>ЗЫ. Чем тут поможет NoSQL? По ним отчеты быстрее строятся? E>>>>>>>а кто сказал что NoSQL тут поможет? G>>>>>>Ты, будешь оправдываться? E>>>пруф где я сказал что NoSQL лучше подходит для построения отчетов, или балабол. G>>Ты утверждал что NoSQL лучше подходит при большом количестве записей. Покачто ты доказываешь обратное.
E>ясно. балабол. я так и думал.
Ты сам с собой разговариваешь? Отойди от зеркала для начала.
Ты хочешь сказать что не утверждал что NoSQL лучше подходят для большого количества записей?
Что ты вообще утверждал в вопросе NoSQL vs RDBMS, или просто потрындеть пришел?
E>>>>дело не в данных, а в специфике самих отчётов. G>>>Ок, что за специфика. Опиши так чтобы другие поняли. E>>внутренняя специфика, договор о не разглашении и все такое прочее. G>Ага, конечно. Слив засчитан.
ну ты же понимаешь что это исключительно твои половые проблемы, на которые всем начхать?
G>>>>>>>>>ЗЫ. Чем тут поможет NoSQL? По ним отчеты быстрее строятся? E>>>>>>>>а кто сказал что NoSQL тут поможет? G>>>>>>>Ты, будешь оправдываться? E>>>>пруф где я сказал что NoSQL лучше подходит для построения отчетов, или балабол. G>>>Ты утверждал что NoSQL лучше подходит при большом количестве записей. Покачто ты доказываешь обратное. E>>ясно. балабол. я так и думал. G>Ты сам с собой разговариваешь? Отойди от зеркала для начала. G>Ты хочешь сказать что не утверждал что NoSQL лучше подходят для большого количества записей? G>Что ты вообще утверждал в вопросе NoSQL vs RDBMS, или просто потрындеть пришел?
я утверждал, при том удачно, что ты балабол.
не вижу смысла в дальнейшей дискуссии.
Здравствуйте, Enomay, Вы писали:
E>>>>>дело не в данных, а в специфике самих отчётов. G>>>>Ок, что за специфика. Опиши так чтобы другие поняли. E>>>внутренняя специфика, договор о не разглашении и все такое прочее. G>>Ага, конечно. Слив засчитан.
E>ну ты же понимаешь что это исключительно твои половые проблемы, на которые всем начхать?
Это вообще-то твои проблемы, не надо на других экстраполировать. Советую всетаки перестать бравировать незнанием и изучить OLAP.
G>>>>>>>>>>ЗЫ. Чем тут поможет NoSQL? По ним отчеты быстрее строятся? E>>>>>>>>>а кто сказал что NoSQL тут поможет? G>>>>>>>>Ты, будешь оправдываться? E>>>>>пруф где я сказал что NoSQL лучше подходит для построения отчетов, или балабол. G>>>>Ты утверждал что NoSQL лучше подходит при большом количестве записей. Покачто ты доказываешь обратное. E>>>ясно. балабол. я так и думал. G>>Ты сам с собой разговариваешь? Отойди от зеркала для начала. G>>Ты хочешь сказать что не утверждал что NoSQL лучше подходят для большого количества записей? G>>Что ты вообще утверждал в вопросе NoSQL vs RDBMS, или просто потрындеть пришел?
E>я утверждал, при том удачно, что ты балабол. E>не вижу смысла в дальнейшей дискуссии.
Ты опять с зеркалом разговариваешь. Отойди от него для начала.
Смысла дискуссии ты не уловил с самого начала. На протяжении десятка постов ты повторил несколько раз кучу заблуждений и слился.
Веди все дискуссии также и в жизни ждет тебя успех.
G>Это вообще-то твои проблемы, не надо на других экстраполировать. Советую всетаки перестать бравировать незнанием и изучить OLAP.
ответ в стиле 3го класса "сам дурак". хотя от тебя иного ожидать и не приходится.
G>Ты опять с зеркалом разговариваешь. Отойди от него для начала. G>Смысла дискуссии ты не уловил с самого начала. На протяжении десятка постов ты повторил несколько раз кучу заблуждений и слился. G>Веди все дискуссии также и в жизни ждет тебя успех.
Здравствуйте, Enomay, Вы писали:
E>предположим — действие — аплоад видео ролика. результат — транскодированное видео в другой формат. E>ну давай, дядя с прямыми руками. расскажи откуда должны руки рости, что бы ответ с необходимым результатом пользователь получил в течении хотя бы 1й минуты.
Кормить ролик по кускам. Имеем возможность отмены, и можно в UI прикуртить прогресс бар.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, Enomay, Вы писали:
E>>предположим — действие — аплоад видео ролика. результат — транскодированное видео в другой формат. E>>ну давай, дядя с прямыми руками. расскажи откуда должны руки рости, что бы ответ с необходимым результатом пользователь получил в течении хотя бы 1й минуты.
___>Кормить ролик по кускам. Имеем возможность отмены, и можно в UI прикуртить прогресс бар.
тоесть, ты обычного, рядового пользователя заставишь нарезать ролик? или сам его будешь резать? а сколько времени на его нарезку необходимо, ты знаешь?
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, Enomay, Вы писали:
G>>>Что же за данные такие, которые нельзя olap_у скормить?
E>>дело не в данных, а в специфике самих отчётов.
___>Я так и представляю пользователей, которые просматривают в отчетах миллиарды строк
откуда такие глупости?
пользователи дальше 1й страницы редко когда заходят. но причем тут это?
Здравствуйте, Enomay, Вы писали:
___>>Кормить ролик по кускам. Имеем возможность отмены, и можно в UI прикуртить прогресс бар.
E>тоесть, ты обычного, рядового пользователя заставишь нарезать ролик? или сам его будешь резать? а сколько времени на его нарезку необходимо, ты знаешь?
А через что он будет заоивать ролик? Вот это самое "через что" и надо правильно написать.
Здравствуйте, Enomay, Вы писали:
E>>>дело не в данных, а в специфике самих отчётов.
___>>Я так и представляю пользователей, которые просматривают в отчетах миллиарды строк
E>откуда такие глупости? E>пользователи дальше 1й страницы редко когда заходят. но причем тут это?
А при том, что предварительно сагригировав данные в для удобоваримой формы для пользователей мы получаем быстрый отчет. Тебе уже сказали как — OLAP, или можно это сделать и руками самому.
E>>откуда такие глупости? E>>пользователи дальше 1й страницы редко когда заходят. но причем тут это?
___>А при том, что предварительно сагригировав данные в для удобоваримой формы для пользователей мы получаем быстрый отчет. Тебе уже сказали как — OLAP, или можно это сделать и руками самому.
расскажешь как их агрегировать, когда их добавляется 25к в секунду, за какой промежуток пользователь захочет данные мы не знаем, а расчет данных самого отчета не ложится на OLAP?
___>>>Кормить ролик по кускам. Имеем возможность отмены, и можно в UI прикуртить прогресс бар. E>>тоесть, ты обычного, рядового пользователя заставишь нарезать ролик? или сам его будешь резать? а сколько времени на его нарезку необходимо, ты знаешь? ___>А через что он будет заоивать ролик? Вот это самое "через что" и надо правильно написать.
ну расскажи как резать ролик на лету при заливке его пользователем. очень хочу на это посмотреть. а потом на стоимость и мощностя железок.
Здравствуйте, Enomay, Вы писали:
E>>>откуда такие глупости? E>>>пользователи дальше 1й страницы редко когда заходят. но причем тут это?
___>>А при том, что предварительно сагригировав данные в для удобоваримой формы для пользователей мы получаем быстрый отчет. Тебе уже сказали как — OLAP, или можно это сделать и руками самому.
E>расскажешь как их агрегировать, когда их добавляется 25к в секунду, за какой промежуток пользователь захочет данные мы не знаем, а расчет данных самого отчета не ложится на OLAP?
Ложится, не ложится — это еще бабушка надвое сказала.
А агрегировать просто — групировать по месяцам допустим. А пользователь может выбирать любой период — просто прибавляем к агрегации за ближайший месяц и полчаем шустрый отчет, а не елозинье по всей таблице с raw input-ом.
Здравствуйте, Enomay, Вы писали:
___>>>>Кормить ролик по кускам. Имеем возможность отмены, и можно в UI прикуртить прогресс бар. E>>>тоесть, ты обычного, рядового пользователя заставишь нарезать ролик? или сам его будешь резать? а сколько времени на его нарезку необходимо, ты знаешь? ___>>А через что он будет заоивать ролик? Вот это самое "через что" и надо правильно написать.
E>ну расскажи как резать ролик на лету при заливке его пользователем. очень хочу на это посмотреть. а потом на стоимость и мощностя железок.
А чем в этом случае ролик отличается от любой последовательности байтов. Берешь и режешь.
___>>>>>Кормить ролик по кускам. Имеем возможность отмены, и можно в UI прикуртить прогресс бар. E>>>>тоесть, ты обычного, рядового пользователя заставишь нарезать ролик? или сам его будешь резать? а сколько времени на его нарезку необходимо, ты знаешь? ___>>>А через что он будет заоивать ролик? Вот это самое "через что" и надо правильно написать.
E>>ну расскажи как резать ролик на лету при заливке его пользователем. очень хочу на это посмотреть. а потом на стоимость и мощностя железок.
___>А чем в этом случае ролик отличается от любой последовательности байтов. Берешь и режешь.
правда? и как, такой ролик плеер нормально откроет?
E>>>>откуда такие глупости? E>>>>пользователи дальше 1й страницы редко когда заходят. но причем тут это? ___>>>А при том, что предварительно сагригировав данные в для удобоваримой формы для пользователей мы получаем быстрый отчет. Тебе уже сказали как — OLAP, или можно это сделать и руками самому. E>>расскажешь как их агрегировать, когда их добавляется 25к в секунду, за какой промежуток пользователь захочет данные мы не знаем, а расчет данных самого отчета не ложится на OLAP? ___>Ложится, не ложится — это еще бабушка надвое сказала. ___>А агрегировать просто — групировать по месяцам допустим. А пользователь может выбирать любой период — просто прибавляем к агрегации за ближайший месяц и полчаем шустрый отчет, а не елозинье по всей таблице с raw input-ом.
это определенно очень круто рассуждать над сферическим конем в вакууме, совершенно не зная предметной области.
Здравствуйте, Enomay, Вы писали:
___>>>>>>Кормить ролик по кускам. Имеем возможность отмены, и можно в UI прикуртить прогресс бар. E>>>>>тоесть, ты обычного, рядового пользователя заставишь нарезать ролик? или сам его будешь резать? а сколько времени на его нарезку необходимо, ты знаешь? ___>>>>А через что он будет заоивать ролик? Вот это самое "через что" и надо правильно написать.
E>>>ну расскажи как резать ролик на лету при заливке его пользователем. очень хочу на это посмотреть. а потом на стоимость и мощностя железок.
___>>А чем в этом случае ролик отличается от любой последовательности байтов. Берешь и режешь.
E>правда? и как, такой ролик плеер нормально откроет?
От жеж смешно тебе, что нос набоку
Теперь моя очередь смеятся
А ты обрати внимание, как на ютубе сделано, может прозрение наступит. Хотя... сомневаюсь.
___>От жеж смешно тебе, что нос набоку ___>Теперь моя очередь смеятся ___>А ты обрати внимание, как на ютубе сделано, может прозрение наступит. Хотя... сомневаюсь.
а как сделано на ютубе? там ролик можно начинать смотреть еще до того как она загрузился?
Здравствуйте, Enomay, Вы писали:
___>>От жеж смешно тебе, что нос набоку ___>>Теперь моя очередь смеятся ___>>А ты обрати внимание, как на ютубе сделано, может прозрение наступит. Хотя... сомневаюсь.
E>а как сделано на ютубе? там ролик можно начинать смотреть еще до того как она загрузился?
Ты из леса что-ли недавно вышел? Можно также ткнуть в середину, и ролик будет грузиться и играть с середины не подгружая начало.
Мы уже победили, просто это еще не так заметно...
