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 терабайта. Совсем другой порядок, не так ли?
а значит это остается пустыми словами.
