Здравствуйте, 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, и много чего другого.
