Есть всем известный сайт 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, а мне это лениво. Меня тут доступ к данным интересует.
