NoSQL: No SQL! No!

Слабаки! Слабаки, всё-таки, авторы термина NoSQL -- Eric Evans и Johan Oskarsson.

Ну зачем теперь всеми миру говорить что NoSQL это "Not Only SQL". Ну все же понимают, что изначально это было "No SQL". Да, это многим не нравится, это многих раздражает и даже пугает негативностью посыла. SQL - символ старого подхода, это и концепция, и конкретные реализации, и "L" как таковой.

Так в этом же и суть. Если вы хотите сделать мир лучше и продвинуть индустрию, нельзя быть мягким и угодить всем. Конечно реляционные базы хороши там где хороши, а нереляционные плохи там где плохи. Но надо обратить на себя внимание и заявить свою позицию всему миру, а значит надо быть плохим, лезть на рожен и многих раздражать. Надо говорить, что всё остальное хуже и только вы знаете путь к свету. Согласитесь, что это работает.

Так что я говорю - No SQL!

Комментарии 28

  1. astur.net.ru написал:

    Поддерживаю!

    Оставлен 13 Декабрь 2009 в 02:58
  2. Артём Семёнов написал:

    Я тоже говорю - NoSQL!

    Оставлен 13 Декабрь 2009 в 03:04
  3. maxp.ya.ru написал:

    О да! Говорить разные передовые слова прикольно :) А что использовать-то в деле?

    В общем, коню понятно, что SQL как таковой это большой идеологический тормоз, однако альтернативы как-то не прельщают пока...

    Оставлен 13 Декабрь 2009 в 09:07
  4. Александр Кошелев написал:

    А что использовать-то в деле?

    Смотря в каком... Вариантов-то много, поэтому выбор зависит от ситуации.

    Оставлен 13 Декабрь 2009 в 11:30
  5. Кирилл Маврешко написал:

    А что использовать-то в деле?

    Лично мне приглянулся MongoDB своей похожестью на хранилище в Google App Engine.

    Как разработчик бекенда MongoDB для Django, авторитетно (а как иначе ;) заявляю, что Django ORM вполне можно использовать с некоторыми NoSQL-хранилищами, т.к. написать бэкенд вполне реально. Не все вещи можно будет воплотить (вроде некоторых агрегатных функций и чересчур мудрённых запросов - всё же Django ORM слишком привязан к SQL), но админка Django работает, как и большинство стандартных приложений (если верить тестам и своим впечатлениям). А это уже многого стоит, мне кажется, т.к. правку данных можно будет доверить стандартной админке Django, а вот логику фронтенда писать используя средства самой базы (там часто и ORM никакой не нужен, т.к. реляционная модель уже отвергнута).

    Оставлен 13 Декабрь 2009 в 21:57
  6. Александр Кошелев написал:

    А это уже многого стоит, мне кажется, т.к. правку данных можно будет доверить стандартной админке Django, а вот логику фронтенда писать используя средства самой базы (там часто и ORM никакой не нужен, т.к. реляционная модель уже отвергнута).

    Полностью согласен. Такого рода решения полезны только с целью завести админки и какой-то минимум других приложений. Во всех остальных случаях надо использовать более подходящий интерфейс к БД.

    Оставлен 14 Декабрь 2009 в 16:41
  7. Сергей Шепелев написал:

    Надо говорить, что всё остальное хуже и только вы знаете путь к свету. Согласитесь, что это работает.

    Угу. А ещё с возрастом это (юношеский максимализм) проходит.

    P.S.: а скачующие троеточия в предпросмотре коментов ты так и не починил.

    Оставлен 14 Декабрь 2009 в 17:42
  8. Александр Кошелев написал:

    Угу. А ещё с возрастом это (юношеский максимализм) проходит.

    Возраст тут не причем. Это банальный маркетинг - продавая свой товар надо говорить что он лучше чем все остальные, если даже это не так на самом деле. Плюс к этом, товар, который продвигает NoSQL движение, имеет явные преимущества и может их продемонстрировать, что добавляет уверености.

    Оставлен 15 Декабрь 2009 в 03:00
  9. Technomage написал:

    Совсем недавно узнал про NOSQL и сразу начал искать информацию в интернете.

    Я прослушал вашу лекцию, почитал статьи, и вот что подумал.

    Большинству сайтов, даже если это нечто инновационное, ведь на самом деле не нужны все фишки реляционности.

    У них есть пользователь (заносим, скажем, документ пользователь в MongoDB), пользователь создает какой-то контент (создаем документ Контент с полем ID-пользователя и полями контента).

    Собственно, реляционность тут только в принадлежности пользователя к контенту (или скажем контент к категории).

    Это же очень простые запросы и очень простая логика.

    И вот что получается, если логика так проста (а при грамотной структуре логика остается простой), а транзакции мало где нужны на самом деле, то возникает первый вопрос:

    1) Так ли нужны на самом деле реляционные ДБ, когда можно построить такую архитектуру на 90-95% сайтов, в которой можно максимум в 3 такта достать все необходимое (достаем статью -> достаем пользователя -> достаем его характеристики)? :)

    Вопрос вопросом, но пока не реляционные БД используют только как второстепенные БД для статистики и т.д.

    Получается второй вопрос:

    2) Можно ли вообще использовать не реляционные БД для всего (сайтов: блогов, соц. сетей, новостных и т.д., где будут хоть какие реляции, типа новость-категория, новость-пользователь и т.д.) или это не оправдывает себя? :)

    Оставлен 15 Декабрь 2009 в 13:05
  10. Сергей Шепелев написал:

    @kpot.oneid.ru

    всё же Django ORM слишком привязан к SQL

    Вы потом ниже написали светлую мысль, что реляционная модель уже отвергнута, но вот эта цитата внутренней борьбы. Нужно вспомнить, что такое ORM. Object-Relational Mapping. Какой, к чертям, бекенд к ORM для нереляционной базы? Что за бред?

    Надо просто признать, что жанга не приспособлена для нереляционных баз (а могла бы). Модели завязаны на ORM, а смысла в этом нет. С другой стороны, если делать правильно, то нужно вводить ещё одну абстракцию "доступ к хранилищу". Одно ответвление будет - через ORM, другие ответвления будут - через свои драйверы, например CouchDB-python, etc. Часть кода из ORM уйдёт в этот слой доступа к хранилищу.

    С другой стороны, не знаю как у монги, а у кауча есть своя админка. Мало чем отличающаяся от жанговской. Модели для форм остаются? Формы всё равно сильно кастомизируются. Модели для поддержания схемы? Её нет. Чем тогда модель отличается от того словаря, который вернёт просто драйвер монги? Особо ничем. Не нужен бекенд и не нужен Django ORM, когда речь идёт о нереляционной базе.

    Оставлен 16 Декабрь 2009 в 01:48
  11. Сергей Шепелев написал:

    Возраст тут не причем. Это банальный маркетинг - продавая свой товар надо говорить что он лучше чем все остальные, если даже это не так на самом деле.

    Саш, это быдлу так надо продавать. В Эльдорадо и Евросети такое любят. Умные люди любят, когда им обстоятельно показывают что и чем лучше, а не лапша на уши "так удобно, верьте".

    Я не говорю, что нереляционные базы хуже, ты знаешь. Но и кричать, что они лучше всех просто так, это ребячество, это непрофессионально.

    Оставлен 16 Декабрь 2009 в 01:52
  12. Сергей Шепелев написал:

    Technomage, хорошие вопросы :)

    Один мой друг сказал, по-моему, гениальную фразу:

    sql это глубоко специфическая технология и нехуй её везде применять.

    Все продукты гугля на нереляционной базе. Это ответ на второй вопрос. Таки да, можно всё сделать без SQL и без реляционных баз.

    На самом деле, с вопросами можно пойти ещё дальше и спросить себя, а нужна ли база вообще? Какие проблемы она решает? Для блогов гиков достаточно одного файла с JSON списком постов и комментариев. На запуске читаем файл в память, на каждом посте переписываем файл заново. Для действительно посещаемых блогов, типа топа ЖЖ есть смысл каждый пост и коменты к нему держать в отдельном файле. Большой объём данных не помещается в память? Значит надо держать в памяти меньше, чем всю историю, загружать по-необходимости. Масса вариантов жить без базы и не тужить.

    Но это кардинальное изменение архитектуры приложения. Тут уже бекендом для жанги не обойдёшься. Есть масса факторов типа "начальник хочет мускл", "программист хочет ORM", которые придётся учесть.

    Оставлен 16 Декабрь 2009 в 02:14
  13. Кирилл Маврешко написал:

    1) Так ли нужны на самом деле реляционные ДБ, когда можно построить такую архитектуру на 90-95% сайтов, в которой можно максимум в 3 такта достать все необходимое (достаем статью -> достаем пользователя -> достаем его характеристики)? :)

    Вы правы, для многих сайтов реляционные БД не нужны совершенно. Прямое доказательство - тот же ORM Django. Казалось бы, ну куда какому-то там ORM'у до настоящего SQL?! А ведь даже до появления в нём агрегатных функций (sum, avg...), его прекрасно хватало на 98% задач.

    Лучшее высказывание на русском по этой теме я видел в блоге "Тру Программиста". Процитирую:

    Нет, я вполне понимаю когда у вас действительно приложение ориентировано на обработку и хранение больших массивов данных. Ну, ERP-системы, всякие хранилища, статистика там, "в прошлом месяце продали сто тыщ карандашей, в этом двести".

    С другой стороны, в большинстве случаев, когда речь идет о десктопных (или веб-) приложениях, где не нужно ворочать миллионами примитивных записей, а приложение работает с относительно высокоуровневыми, сложными объектами, суть "дизайна и проектирования баз данных" заключается в повторении двух действий:

    а) расколупать эти высокоуровневые объекты на кучу простейших полей — чисел, строк и сложных зависимостей между ними, и раскидать между десятками таблиц. Обычно это не очень сложно, однако некоторые (или многие?) типы данных не так уж приятно и органично раскладываются в этой модели — например, теги у записей в блоге;

    б) затем упорно собирать эти поля в объекты обратно, пользуясь четырехэтажными JOIN'ами, мегабайтами кода врапперов, кривыми и не очень слоями ORM — в зависимости от квалификации разработчика, в общем, всячески преодолевать пресловутый O/R impedance mismatch. При этом и рукописные JOIN'ы не показывают чудеса производительности и гибкости, а сгенеренные автоматически умным слоем врапперов — тем более.

    Так что реляционные базы очень даже хороши для определённых случаев. Например, Python хорош, пока тебе важнее скорость разработки, а не максимальная скорость вычислений.

    Но если у вас огромное количество клиентов, вы всё равно не сможете постоянно запускать сложные запросы - ни одна система не выдержит. И всё равно придётся идти на уловки - денормализацию, кэширование, сбор статистики по ходу работы, а не в конце её, и т.п. Т.е. MySQL я использую или CouchDB - большой разницы уже не будет, т.к. реляционная база полностью потеряет свои преимущества. Осталось добавить, что MySQL масштабируется очень плохо и однажды потребует переписать всё для использования шардинга, а CouchDB масштабируется линейно "из коробки", и переписывания кода в будущем не потребует, а сам код не будет переусложнён деталями реализации масштабирования (вроде таких).

    Оставлен 16 Декабрь 2009 в 09:23
  14. Сергей Шепелев написал:

    @Кирилл Маврешко

    MySQL масштабируется очень плохо и однажды потребует переписать всё для использования шардинга, а CouchDB масштабируется линейно "из коробки"

    Вобще-то CouchDB масштабируется по объёму данных ровно так же, как MySQL. То есть не масштабируется. Можно делать разные приёмы:

    • master/slave репликации и читать с разных slave. Это не масштабирование записи.
    • шардирование и писать на разные машины. И потерять кусок данных, когда одна выйдет из строя.
    • совместить два этих подхода. В любом случае всё делается на клиенте, никакого mysqlproxy для дивана нет.

    С тем же успехом можно сказать, что BDB масштабируется или файловая система. Мол, делайте scp на две машины, а не на одну, вот вам и масштаб. И зачем люди ломали голову, придумывали распределённые файловые системы...

    BigTable, Voldemort, Riak, Scalaris масштабируются по объёму данных из коробки. CouchDB пока нет, увы.

    Оставлен 16 Декабрь 2009 в 22:39
  15. Кирилл Маврешко написал:

    @Сергей Шепелев

    Вобще-то CouchDB масштабируется по объёму данных ровно так же, как MySQL. То есть не масштабируется.

    Я привёл CouchDB лишь как пример нереляционной базы с претензией на хорошее масштабирование из коробки. Как хорошо оно сейчас работает - это отдельный разговор. Вместо CouchDB можно с тем же успехом поставить Cassandra, Hypertable или HBase. Основная идея была в том, что если потом всё равно придётся переписывать и отказываться от плюшек реляционной базы - почему бы сразу не пойти другим путём - изначально более прямым. Мы же не режем хлеб бензопилой, и не чешем спину пятками. Хотя можно ведь приноровиться!

    Какой, к чертям, бекенд к ORM для нереляционной базы? Что за бред?

    Бекенд к ORM для нереляционной базы - это не бред (и давайте воздержимся от резких слов). Стандартное API MongoDB по стилю использования очень похоже на Django ORM. А это значит, что запись в Django ORM можно достаточно линейно преобразовать в аналогичную на MongoDB API. Это и делает бэкенд. Причин так делать - много. Во-первых, у MongoDB нет админки, как у Django. Во-вторых, это позволяет использовать уже написанный для Django ранее код. Даже если не весь, всё равно - это уже значительная экономия времени. Повторяю, писать новый код на Django ORM я бы после этого не стал, но это не отменяет полезности инструмента.

    Надо просто признать, что жанга не приспособлена для нереляционных баз (а могла бы). Модели завязаны на ORM, а смысла в этом нет. С другой стороны, если делать правильно, то нужно вводить ещё одну абстракцию "доступ к хранилищу". Одно ответвление будет - через ORM, другие ответвления будут - через свои драйверы, например CouchDB-python, etc. Часть кода из ORM уйдёт в этот слой доступа к хранилищу.

    Напротив, архитектурно Django ORM приспособлен для нереляционных баз. Там есть абстрагирование от движка базы, можно определить свои варианты QuerySet и прочих служебных классов, можно предоставлять разный набор функционала для разных бэкендов.

    Беда лишь в том, что на уровне кода многое сделано несовершенно, не доведено до конца (я в этом коде много копался). Предусмотрено слишком мало возможностей для изменения поведения. Слишком много написано с оглядкой на генерацию именно SQL-запросов, а не произвольных инструкций, и именно для реляционной базы. Всё это - не более, чем родовые травмы, вполне операбельные. Правда операцию эту должен проводить лично автор ORM - Малкольм Трединник, вряд ли кто-то другой сумеет провести её качественно. Я, например, откровенно побаиваюсь.

    Если операцию провести, то QuerySet API потеряет единство - придётся поделить функционал на "базовый" и "зависимый от хранилища": "функции для реляционных баз", "для CouchDB", "Для Cassandra версии 0.9x". Тут я с вами согласен. И это неплохо, я считаю! Разработчик будет знать, что если он напишет код под базовый функционал, то он будет работать где угодно. Но и простор для оптимизаций у него тоже будет.

    Остаётся надеяться, что в будущем что-то подобное появится. Увы, я сам не располагаю ни временем, ни достаточным знанием английского для таких масштабных переделок :( И нет никакой уверенности, что другие разработчики (на) Django со мной бы согласились. Судя по тому, что в версии 1.2 они обещают вообще вот такое чудо:

    Entry.objects.raw('select * from blog_entry')
    
    Оставлен 18 Декабрь 2009 в 11:11
  16. Александр Кошелев написал:

    Саш, это быдлу так надо продавать.

    Так недалеких и зависимых большинство!

    Умные люди любят, когда им обстоятельно показывают что и чем лучше, а не лапша на уши "так удобно, верьте".

    Я в этом посте не говорю про характеристики тех или иных систем и даже не называю имен, а рассуждаю на тему движения в целом.

    Я не говорю, что нереляционные базы хуже, ты знаешь. Но и кричать, что они лучше всех просто так, это ребячество, это непрофессионально.

    Я кричу NoSQL, т.к. если бы я кричал NoSQLWhatIsXTimesFasterThanYourFavouriteRDBMS, то было бы ещё хуже.

    Время для детального и конкретного разбора ещё придет.

    Оставлен 19 Декабрь 2009 в 03:18
  17. Александр Кошелев написал:

    автор ORM - Майкл Тредник

    Malcolm Tredinnick -- Малкольм Трединник

    Оставлен 19 Декабрь 2009 в 03:24
  18. Кирилл Маврешко написал:

    Malcolm Tredinnick -- Малкольм Трединник

    Ой, и правда. Виноват, писал по памяти.

    Оставлен 19 Декабрь 2009 в 06:15
  19. Сергей Шепелев написал:

    @Кирилл Маврешко

    если потом всё равно придётся переписывать и отказываться от плюшек реляционной базы - почему бы сразу не пойти другим путём - изначально более прямым. Мы же не режем хлеб бензопилой, и не чешем спину пятками. Хотя можно ведь приноровиться!

    Здесь вы совершенно правы, всеми руками за. И более того, (почти) никто не использует плюшек (констрейнты, триггеры по предметной области и пр.) реляционной базы. А учитывая, что, опять же, у многих объём данных не превышает 500мб, выбор реляционной базы в качестве хранилища выглядит совершенно детским и неосознанным (просто все так делают, да ещё и инструменты типа Django навязывают RDBMS).

    Бекенд к ORM для нереляционной базы - это не бред

    Простите за резкое слово, более удачным будет ENOSENSE. В выражении "non-relational DB backend for object relational mapping" отсутствует смысл. Я писал об этом выше.

    запись в Django ORM можно достаточно линейно преобразовать в аналогичную на MongoDB API

    Конечно. И это получится уже не Django ORM, а Django DB-API (а у него, одной из реализаций будет ORM). Именно к этому я и клонил с самого начала.

    Напротив, архитектурно Django ORM приспособлен для нереляционных баз.

    Архитектурно HTTP приспособлен для раздачи уймы разнотипного контента через многих посредников. А на практике, почему-то получается не так радужно всё. И вот этот пример из 1.2 наглядно показывает куда смотрят разработчики жанги, чего они хотят от своего продукта. А в кауче, кстати, есть своя встроенная админка. Да, не такая удобная, но реализует точь-в-точь тот же workflow: пришёл админ, подредактировал строку, ушёл. И что, ради этого держаться за жангу?

    Беда в том, что не получится взять и переключить в настройках использование реляционной базы на нереляционную. Всё приложение должно быть спроектировано под конкретные технологии. Тогда и плюшки будут, и гемору от impedance mismatch неоткуда взяться.

    Оставлен 21 Декабрь 2009 в 16:16
  20. Powerman написал:

    На мой взгляд, обсуждаемая проблема гораздо глубже, чем просто выбор реляционной базы или не реляционной. На самом деле это выбор "думать" или "не думать" в процессе разработки хранилища данных.

    SQL это "good enough" решение для мелких и средних проектов, да и для многих больших тоже. Универсальное (любые данные, любые выборки), единообразное (одинаковый доступ к любым данным), с кучей подготовленных специалистов. И эти специалисты уже давно не включают мозг в процессе конвертации данных приложения в формат реляционной базы - всё делается механически. Даже редкие денормализации и оптимизации делаются механически. Расплатой за это является довольно гадкий код по конвертации данных приложения в SQL и обратно - но и эту задачу "механизировали" с помощью ORM (да, ценой потери некоторой гибкости и производительности, но для мелких/средних проектов это обычно не чувствительно).

    Никакой лучшей альтернативы SQL с теми же характеристиками - чтобы можно было всё делать механически но работало всё быстрее, лучше масштабировалось и код был элегантнее - на данный момент нет.

    Все альтернативные хранилища данных не универсальны в той же мере, что и SQL. Нужно анализировать данные приложения, требуемые выборки по этим данным, объёмы данных... и уже по результатам этого анализа выбирать подходящее хранилище, будь то CouchDB или файлы в формате JSON. Причём данные приложения могут быть достаточно разными, и одни может оказаться удобнее хранить в файлах, другие в документ-ориентированной базе, третьи в реляционной - т.е. мы уже жертвуем единообразностью доступа к данным. Механически всё это делать очень проблематично. Ну и, в теории, может возникнуть такая ситуация, что, из-за незначительного изменения постановки задачи заказчиком, изменится характер данных... и теперь для этих данных более предпочтительным окажется другое хранилище - т.е. потребуется куча дополнительной работы.

    Мы уже написали несколько небольших задач без использования SQL, и наступили на некоторые из описанных в предыдущем абзаце нюансов. Да, код получается намного проще, скорость работы увеличивается, и т.д. и т.п. С одной стороны. С другой - при разработке хранилища данных приходится думать (что лично я считаю плюсом, но большинство со мной не согласится), в некоторых случаях теряется универсальность (возможность делать любые выборки по данным без написания нового кода), плюс в сложных случаях приходится жертвовать единообразностью доступа к данным.

    Мы все эти проблемы в некотором смысле "обошли": у нас используется сервис-ориентированная архитектура. Каждый сервис "владеет" своим, небольшим, куском данных - напр. базой пользователей, или информацией об авторизации, etc. Соответственно, в рамках одного сервиса данные достаточно однотипные, для них используется какое-то одно хранилище, и единообразность доступа к данным на уровне сервиса сохраняется. На уровне всей системы в целом единообразность доступа к данным тоже сохраняется, т.к. ко всем данным доступ идёт через сетевое RPC к сервисам. Универсальности в плане возможности делать любые выборки нет, но это уже связано не столько с отказом от реляционных баз, сколько с сервис-ориентированной архитектурой - у всех сервисов свои интерфейсы, и если в интерфейсе нет возможности делать какие-то запросы по данным, то всё-равно нужно писать код и менять интерфейсы, чтобы такая возможность появилась.

    Резюмируя: пока нам нравится, как всё работает, и желания возвращать все данные в MySQL у нас нет. Но разница в подходах громадная, и, в первую очередь, тем, что вместо того, чтобы тупо автоматически набрать несколько CREATE TABLE и вернуться к работе над логикой приложения, приходится тратить время на анализ данных, выборок и продумывание структуры хранилища.

    Оставлен 22 Декабрь 2009 в 01:01
  21. Сергей Шепелев написал:

    Powerman, спасибо вам за такой развёрнутый и полезный комментарий.

    Вот, Саша, понимаешь теперь почему кричать No SQL! бессмысленно? "Недалёкие и зависимые", кто не умеют и не хотят думать, допустим пойдут на зов, нарвутся на кучу проблем (потому что CouchDB/MongoDB/etc не 1:1 замена SQL базам) и ты будешь виноват (справедливо), потому что их надо заставлять думать, а не использовать X.

    Оставлен 22 Декабрь 2009 в 16:50
  22. Сергей Шепелев написал:

    Вдогонку: а иначе (если люди будут так же бездумно использовать нереляционные базы, как сейчас реляционные), опять понапишут тысячи ORM и опять будет такое же использование инструмента не по назначению.

    Потом появится NotNoSQL и ты будешь кричать, что он лучше чем NoSQL?

    Оставлен 22 Декабрь 2009 в 21:38
  23. Александр Кошелев написал:

    Вот, Саша, понимаешь теперь почему кричать No SQL! бессмысленно? "Недалёкие и зависимые", кто не умеют и не хотят думать, допустим пойдут на зов, нарвутся на кучу проблем (потому что CouchDB/MongoDB/etc не 1:1 замена SQL базам) и ты будешь виноват (справедливо), потому что их надо заставлять думать, а не использовать X.

    Я вот что понял, что ты не понял о чем я написал пост:-)

    Я писал не про то что что-то лучше или хуже, а про способ подачи и продажи свой концепции. Ты зацепился за знакомые маячки -- CouchDB, MongoDB и т.п. и пошел обсуждать их. А я говорил не про них конуртено.

    Предметное обсуждение, тестирование и предложений своих решений только впереди.

    Оставлен 25 Декабрь 2009 в 01:02
  24. Александр Кошелев написал:

    Кириллу и Пауэрмену спасибо за интересные комментарии.

    Оставлен 25 Декабрь 2009 в 01:02
  25. Константин написал:

    Очень интересная дискуссия у вас получилась, я читал с удовольствием. Но некоторые моменты остались непонятными (простите, я не программист, а скорее менеджер проекта, но технические детали меня интересуют в первую очередь). Зачем нереляционные хранилища использует Google - это понятно (миллиарды документов индекса хранить проще в виде документ-ориентированной БД, чем в SQL, или по крайней мере дешевле), а вот сервисы UGC (User Generated Content или пресловутый web2.0) всяческие блоги, форумы, соцсети. Что лучше для таких сайтов? По сути - это тоже в основном документы (например пост в блоге или тема в форуме), но имеют зависимости с некоторыми "реляционными" объектами: теми же тегами или рейтингами пользователей. В социальной сети, даже построенной преимущественно на UGC таких зависимостей может быть очень много. С другой стороны, контента (документов) там так же много и выбирая нереляционную базу мы выигрываем..?

    Заранее прошу прощения за сумбур, просто продумываю сейчас концепцию одного такого UGC проекта, а идея посмотреть куда-то дальше MySQL была давно.

    Оставлен 11 Январь 2010 в 00:14
  26. EvgIq написал:

    Добрый день!

    Очень интересно было почитать.

    Эх, SQL уже 40 лет существует, а споры по его замене - не утихают, продолжаясь с момента его появления.

    Мое мнение - SQL (РБД) еще всех переживет(ут) :)

    Powerman - очень интересный и поучительный опыт вы описали, спасибо.

    Настораживает только предвзятое отношение к "SQL'истам" как к людям "не думающим", и не "включающим мозг", ищущих постоянно, так сказать легких, путей (что само по себе и не плохо в нашем программерском случае) :-)

    И конечно же я не соглашусь с тем, что чем больше надо думать (читай - тратить время) при создании (и не дай бог - изменении) структуры ДБ, тем лучше. Это не означает, что я за непродуманные структуры РБД сами по себе.

    Т.е. вы своим постом невольно подтвердили мое мнение, изложенное вначале. Дай бог (это искренне), чтобы вам не пришлось назад все переделывать на MySQL или другую РДБ, т.к. такие проекты так же должны существовать.

    Из минусов SQL, я так понял, здесь приводят необходимость "разбирать" данные, а затем их снова "собирать", и связанные с этим прочие накладные расходы. Так извините - универсальность, как же без этого? Не буду приводить банальные параллели из жизни

    И Гугл упомянули. Это конечно аргумент. Но только Гугл может себе позволить иметь и развивать свою БД, какую ему надо. И потом - РДБ, наверняка он тоже использует.

    А спорить и размышлять по этому поводу (типам "лучшей" БД) - надо! Это полезно, и даже приятно :)

    Оставлен 11 Январь 2010 в 08:44
  27. EvgIq написал:

    Забыл добавить к обращению к Powerman'у: Основные принципы РДБ - интуитивно понятны, поэтому и не требуют излишнего "напряжения мозгов". И это, я отношу, к несомненным плюсам.

    Оставлен 11 Январь 2010 в 09:12
  28. Powerman написал:

    @EvgIq

    О каком "обращении" речь?

    Что касается "интуитивно понятных" принципов реляционных баз - я помню как изучал их сам, и как потом учил других - это не было простым и интуитивно понятным процессом. Да, сами принципы просты, но вот понимание того, как применять их на практике - зачем данные хранить именно в таком, абсолютно неудобном и не естественном виде, и как имеющиеся данные конвертировать в/из формат таблиц в базе - приходит далеко не интуитивным путём.

    Что касается напряжения мозга, то ответ прост: одну и ту же проблему можно решить разными способами. Например, вы в лодке, она дала течь, и вы можете утонуть. Варианты действий:

    • начать немедленно вычерпывать воду кружкой (самое как бы простое и интуитивно понятное решение, не требующее напряжения мозга)
    • придумать, сделать и установить помпу, которая будет выкачивать воду сама (самое интересное и творческое решение, правда можно не успеть всё это сделать до того, как вы утонете)
    • оглядеться, выяснить что лодка стоит рядом с берегом, и выйти из лодки на берег (мыслить "out of box", выйти за рамки системы - и вот это действительно самое простое решение)

    Первый вариант - это и есть использование реляционных баз не включая мозг. Он кажется самым простым и интуитивно понятным только пока вы во-первых думаете внутри системы, не пытаясь выйти за рамки, и во-вторых расплатой за то, что вы не включали мозг служит бесконечная нудная механическая работа по вычёрпыванию воды... которая к тому же обладает проблемой масштабирования - течь может усилиться настолько, что вы уже не сможете вычёрпывать воду быстрее, чем она прибывает.

    Безусловно, приведённая выше аналогия ложна, как любые аналогии... но, надеюсь, мою мысль на тему напряжения мозга она передаёт. :)

    Оставлен 11 Январь 2010 в 23:36