Всегда будут те, кто чем-то недоволен - о чём же говорить, если всё хорошо? Так что, на информационный шум можно забить. Но под криком души - подписываюсь однозначно.
Почитал про кеширование в монго и используемую технологию - в принципе, как и написано - "зависит от реализации менеджера виртуальной памяти ОС", то бишь за кеширование отвечает на самом деле операционная система, так же как за кеширование кода и небольших объёмов данных - алгоритмы процессора. Полагаю это по-умолчанию справедливо для большинства баз.
> Но я не жалею. Теперь могу вполне выбирать именно нужное. Все-таки опыт.
Вот с этим, да и всё сообщение с этим - абсолютно согласен. Всё нужно попробовать. Но "опыт - сын ошибок трудных", его где угодно приобретать, но не на проектах которые имеют дедлайн. Впрочем - это тоже опыт и такое бывало ))
А вообще, я смотрю у крупных контор достаточно распространена практика разные части проектов делать на разных технологиях. Видимо таким образом обкатывают новые технологии и получают опыт на некритичных участках.
> With relational databases, object caching is usually a separate facility (such as memcached), which makes sense as even a RAM page cache hit is a fairly expensive operation with a relational database (joins may be required, and the data must be transformed into an object representation). Further, memcached type solutions are more scaleable than a relational database.
Абзац манипулятивный. Реляционные базы (ладно, не буду за все) прекрасно умеют такие трюки, без них - потеря производительности в десятки раз. Но почему-то главные аргумент: "придут злые джойны и всё заберут!" - как знамя у NoSQL, хотя джойн - это лишь одно из условий выборки, которое тоже может вполне разместиться в кэше (а если джойн становится причиной просадки в производительности - почему бы не денормализовать?). На уровне, когда приложение (НЕ БАЗА!) использует memcached, приложение берёт уже обработанные данные, вообще не обращаясь к базе (строго говоря, memcached - это тоже база, частный случай NoSQL - со своими "ключ-значение", тегами и кластеризацией). Поэтому сравнение сложного приложения с распределением данных на две базы и приложения запросы которого вмещаются в кэш процессора - как-то... Я не думаю, что кто-то откажется кешировать в памяти сложные обработанные данные, вместо обработки их, пусть даже в кеше процессора.
> Просто почитайте, попробуйте и вы поймете где сахар, а где гвозди. Беспричинно денормализовывать тут тоже не надо - везде есть предел.
Ну, именно такое впечатление получилось из статьи. Возможно не хватает жизненных примеров - как это выглядит на практике?
Я с недавних пор использую монго в одном проекте - прицениваюсь к базе. Перед этим был коуч, который на фоне монго выглядит весьма бледно. Тесты делал - под конкретные свои задачи, о преимуществе Mongo в производительности ничего не могу сказать, но сравнивал я с Postgres - в большинстве случаев postgres ухитряется быть быстрее, но возможно тут сказывается, что всё-таки с ним у меня опыта больше и монго можно было бы ещё "подкрутить".
До того уровня, когда задачи простые, принципиальной разницы нет и монго можно выбрать именно за "сахар" - бессхемная база проще в плане поддержки, обещана простая кластеризация. Распределённая файловая система интегрированная в базу - тоже очень приятна.
Но как только задачи начинают усложняться, вдруг оказывается, что монго - это просто недостроенное здание - у него нет верхних этажей! Да, про это здесь тоже упоминалось - сложные запросы это не родная стихия монго, а многие - он просто даже не поддерживает. Бессхемность оборачивается сложностью сопровождения, условную схему хранения нужно уже документировать, чтобы знать, что приложение ожидает от данных, да и разных данных перемешано прилично, но база контролировать соответствие схеме - не будет.
Поэтому, не всё так однозначно. В проектах, где есть уверенность, что проект никогда не перерастёт простые задачи - монго, в современном его состоянии вполне может занять нишу mysql и хитрое телодвижение Оракла, загрёбшего лакомый кусочек и вместе с тем слабое звено с рынка БД, здесь не удалось. Но вот когда вдруг окажется, что нужно больше, чем монго может дать, возможно придётся менять коней на переправе.
> если в СУБД обнаружится фатальный баг, кого проще найти С++-кодера или Ерланг?
Тут какое-то противоречие. Эрланг нужен для крутых проектов, где нон-стоп 24/7/365. Полагаю такие конторы не только найдут, но и держат про запас.
А конторы, которые это нафиг не впало, ибо уровень не тот, и базу сами колупать не будут, ибо не каждый C++ кодер это осилит, поскольку дело не в количестве, а в качестве - эрланг учат как раз для работы над критичными проектами.
И в конце концов: фатальный баг в СУБД - это дело, которым озаботится весь мир, а не отдельные конторы.
Всё вышесказанное - это о языке, как критерии, а не о конкретных СУБД на нём написанных )
> Философия mongo диктует нам использовать вложенные массивы, когда мы бы использовали JOIN в SQL. То есть список категорий надо делать не отдельной таблицей, а вставлять массивом в поле categories у каждой новости
Это что, в каждой статье хранится всё дерево категорий? Или как это понимать? Как происходит редактирование такого дерева категорий? Вот сеошники обнаружили, что одну категорию надо бы переименовать, ибо... и что, одним махом обновляются все статьи? Тысяча? Десять тысяч? Сто тысяч? Да и монго бралось не для таких детских размеров - оно ж под кластер заточено. А как в такой системе формируется меню с этим деревом категорий? Запросом ко всем N тысяч?
Не слишком ли высокие накладные расходы на ровном месте философии?
Беспричинная денормализация - такое же зло, как и беспричинная нормализация. А то следуя такой логике во избежание лишних джойнов мы должны в каждом комментарии, в каждой статье хранить полный профиль пользователя, их создавшего? Как-то это нездорово.
> + Когда число записей в разы превышает число чтений
Вот это и интересно - а с чем сравнивалось? Реляционные базы запись выполняют медленнее? У них принципиально другое железо или они пишут больше данных?
> + Огромные запросы на выборку разных наборов данных с их аналитикой
А с чего у нас начинается огромность?
SELECT id FROM tbl WHERE a > b - это огромный запрос?
> - Ну и последний и очевидный недостаток, который не относится монго, но важен, так это то, что с ним нет хостингов
Здесь как раз всё далеко не так плохо - давно уже хватает VPS по цене обычного виртуального хостинга.
> А теперь представим, что к новости нужны теги. Это еще одна таблица тегов. У новости может быть много тегов. Это еще одна таблица соотношений новость-тег. А к новости нужны комментарии. Еще таблица комментариев. Один запрос обрастает 10 JOIN'ами с другими таблицами.
Повеситься - выбирать новость с тегами и комментариями одним запросом! И судя по тону аффтар на этом не остановится.
Чувак, читай дальше ста страниц, бери не триальные версии книг!
Комментарии
Свежее
BlogRoll
Жена
themylogin
dessko
Комментарии пользователя с IP: 178.216.127.205
Керниган и Ричи Inc.
Так что, на информационный шум можно забить.
Но под криком души - подписываюсь однозначно.
Коллективный переход на электронные лекции. Личный опыт
http://habrahabr.ru/blogs/study/40236/
MongoDB
Вот, немного, про кэширование в постгрес http://www.sai.msu.su/~megera/postgres/talks/what_is_postgresql.html#buffer_management
MongoDB
Вот с этим, да и всё сообщение с этим - абсолютно согласен. Всё нужно попробовать. Но "опыт - сын ошибок трудных", его где угодно приобретать, но не на проектах которые имеют дедлайн. Впрочем - это тоже опыт и такое бывало ))
А вообще, я смотрю у крупных контор достаточно распространена практика разные части проектов делать на разных технологиях. Видимо таким образом обкатывают новые технологии и получают опыт на некритичных участках.
MongoDB
Абзац манипулятивный. Реляционные базы (ладно, не буду за все) прекрасно умеют такие трюки, без них - потеря производительности в десятки раз. Но почему-то главные аргумент: "придут злые джойны и всё заберут!" - как знамя у NoSQL, хотя джойн - это лишь одно из условий выборки, которое тоже может вполне разместиться в кэше (а если джойн становится причиной просадки в производительности - почему бы не денормализовать?). На уровне, когда приложение (НЕ БАЗА!) использует memcached, приложение берёт уже обработанные данные, вообще не обращаясь к базе (строго говоря, memcached - это тоже база, частный случай NoSQL - со своими "ключ-значение", тегами и кластеризацией). Поэтому сравнение сложного приложения с распределением данных на две базы и приложения запросы которого вмещаются в кэш процессора - как-то... Я не думаю, что кто-то откажется кешировать в памяти сложные обработанные данные, вместо обработки их, пусть даже в кеше процессора.
MongoDB
Ну, именно такое впечатление получилось из статьи. Возможно не хватает жизненных примеров - как это выглядит на практике?
Я с недавних пор использую монго в одном проекте - прицениваюсь к базе. Перед этим был коуч, который на фоне монго выглядит весьма бледно. Тесты делал - под конкретные свои задачи, о преимуществе Mongo в производительности ничего не могу сказать, но сравнивал я с Postgres - в большинстве случаев postgres ухитряется быть быстрее, но возможно тут сказывается, что всё-таки с ним у меня опыта больше и монго можно было бы ещё "подкрутить".
До того уровня, когда задачи простые, принципиальной разницы нет и монго можно выбрать именно за "сахар" - бессхемная база проще в плане поддержки, обещана простая кластеризация. Распределённая файловая система интегрированная в базу - тоже очень приятна.
Но как только задачи начинают усложняться, вдруг оказывается, что монго - это просто недостроенное здание - у него нет верхних этажей! Да, про это здесь тоже упоминалось - сложные запросы это не родная стихия монго, а многие - он просто даже не поддерживает. Бессхемность оборачивается сложностью сопровождения, условную схему хранения нужно уже документировать, чтобы знать, что приложение ожидает от данных, да и разных данных перемешано прилично, но база контролировать соответствие схеме - не будет.
Поэтому, не всё так однозначно. В проектах, где есть уверенность, что проект никогда не перерастёт простые задачи - монго, в современном его состоянии вполне может занять нишу mysql и хитрое телодвижение Оракла, загрёбшего лакомый кусочек и вместе с тем слабое звено с рынка БД, здесь не удалось. Но вот когда вдруг окажется, что нужно больше, чем монго может дать, возможно придётся менять коней на переправе.
MongoDB
Тут какое-то противоречие. Эрланг нужен для крутых проектов, где нон-стоп 24/7/365. Полагаю такие конторы не только найдут, но и держат про запас.
А конторы, которые это нафиг не впало, ибо уровень не тот, и базу сами колупать не будут, ибо не каждый C++ кодер это осилит, поскольку дело не в количестве, а в качестве - эрланг учат как раз для работы над критичными проектами.
И в конце концов: фатальный баг в СУБД - это дело, которым озаботится весь мир, а не отдельные конторы.
Всё вышесказанное - это о языке, как критерии, а не о конкретных СУБД на нём написанных )
MongoDB
У монго свой механизм или она пользуется кэшем OS?
MongoDB
> Философия mongo диктует нам использовать вложенные массивы, когда мы бы использовали JOIN в SQL. То есть список категорий надо делать не отдельной таблицей, а вставлять массивом в поле categories у каждой новости
Это что, в каждой статье хранится всё дерево категорий? Или как это понимать? Как происходит редактирование такого дерева категорий? Вот сеошники обнаружили, что одну категорию надо бы переименовать, ибо... и что, одним махом обновляются все статьи? Тысяча? Десять тысяч? Сто тысяч? Да и монго бралось не для таких детских размеров - оно ж под кластер заточено. А как в такой системе формируется меню с этим деревом категорий? Запросом ко всем N тысяч?
Не слишком ли высокие накладные расходы на ровном месте философии?
Беспричинная денормализация - такое же зло, как и беспричинная нормализация. А то следуя такой логике во избежание лишних джойнов мы должны в каждом комментарии, в каждой статье хранить полный профиль пользователя, их создавшего? Как-то это нездорово.
> + Когда число записей в разы превышает число чтений
Вот это и интересно - а с чем сравнивалось? Реляционные базы запись выполняют медленнее? У них принципиально другое железо или они пишут больше данных?
> + Огромные запросы на выборку разных наборов данных с их аналитикой
А с чего у нас начинается огромность?
SELECT id FROM tbl WHERE a > b - это огромный запрос?
> - Ну и последний и очевидный недостаток, который не относится монго, но важен, так это то, что с ним нет хостингов
Здесь как раз всё далеко не так плохо - давно уже хватает VPS по цене обычного виртуального хостинга.
MongoDB
Повеситься - выбирать новость с тегами и комментариями одним запросом! И судя по тону аффтар на этом не остановится.
Чувак, читай дальше ста страниц, бери не триальные версии книг!