NoSQL: Нереляционные хранилища

Пора нарушить молчание и рассказать о том, что на недавней замечательной конференции 404fest я тоже имел честь выступать с докладом. Посвящен он был модной ныне теме - NoSQL. Доклад получился коротким и поэтому больше политическим чем техническим. Я хотел показать, что этот новый тренд не просто так захватывает умы всё большего числа разработчиков.

Это только первое моё выступление на эту тему, но, я надеюсь, что в скором времени последуют другие на новых площадках


View more documents from Alex Koshelev.

Update: а вот и видео подоспело:

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

  1. http://glader.livejournal.com/ написал:

    Какой смысл в слайдах без голоса :)

    Оставлен 17 Октябрь 2009 в 12:51
  2. Александр Кошелев написал:

    Согласен, эти слайды без слов почти бесполезны:-) Больше для истории выложил.

    Надеюсь скоро появится видеозапись.

    Оставлен 17 Октябрь 2009 в 15:07
  3. V@s3K написал:

    Хотелось бы уточнить. ORM дают аналогичные удобства. И YAML и простые выборки (хотя еще иногда вопрос, что проще: написать SQL-запрос, или разбираться с этими "удобствами"). В чем же плюсы этого, кроме того, что не нужен DB-сервер?

    Оставлен 17 Октябрь 2009 в 19:50
  4. igorekk написал:

    V@s3K, плюсы хотя бы в том, что не любую задачу можно просто и безболезненно положить на реляционную базу данных.Тот же пресловутый EAV, к примеру. Несколько дней назад смотрел питоновские биндинги для MongoDB. Остался приятно удивлён. Имеются даже фреймворки, предоставляющие ORM a-la Django. PS. Ждём видео :)

    Оставлен 17 Октябрь 2009 в 21:40
  5. Сергей Шепелев написал:

    Я имел удовольствие поработать с CouchDB версии 0.9 с базой в 300К документов.

    Действительно, всё что описано - правда, она прекрасна. За одним исключением, которое моментально ставит крест на всём (для меня) - временные вьюхи на базе в сотни тысяч документов выполняются буквально часами. И нельзя попросить остановиться после первых 100 документов. То есть отлаживать новые запросы на живой базе невозможно. Они (на freenode #couchdb) всерьёз предлагают скопировать 2-3К случайно выбранных документов в отдельную базу и испытывать вьюхи там где это быстро. А в остальном база отличная.

    MongoDB прикольная. Но вытащить из неё больше тысячи документов - очень долго. Авторы говорят, что это питонский драйвер виноват. Пользователям как бы не очень важно кто именно виноват. С другой стороны не всегда нужно таскать много документов. Монга прикольная.

    select count(*) from user where now() < registered - interval ?; ['two weeks'] такое вам в кошмарах не снилось? Очень гламурненько, по-моему.

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

    Оставлен 20 Октябрь 2009 в 03:15
  6. Александр Кошелев написал:

    Сергей, спасибо за мнение.

    Я сам имел уже опыт использования CouchDB с парой-тройкой сотен тысяч документов (правда не очень больших) и, да, временные вьюхи дейтсивтельно на порядок медленнее перманентных. Не часы конечно, но минуты на выполнение требуют.

    Монго, опять-таки, по моему опыту очень быстрый причем как на запись, так и на выборки такого же объема данных. Но уж очень он концептуально неоднороден, на мой взгляд. Кажется что его разработчики сами не знают чего хотят. Вот недавно добавили map/reduce для запросов. Зачем?

    Оставлен 20 Октябрь 2009 в 11:26
  7. Александр Кошелев написал:

    Обновил пост - видео приехало.

    Оставлен 24 Октябрь 2009 в 14:00
  8. igorekk написал:

    Александр, спасибо за видео. У меня назрел такой вопрос. Имеет ли вообще смысл спользовать реляционные и нереляционные БД в одной упряжке? Хочется странного, наверное. Часть информации хранить в *SQL, а часть в MongoDB, к примеру.

    Оставлен 29 Октябрь 2009 в 11:38
  9. Александр Кошелев написал:

    Имеет ли вообще смысл спользовать реляционные и нереляционные БД в одной упряжке? Хочется странного, наверное. Часть информации хранить в *SQL, а часть в MongoDB, к примеру.

    Конечно имеет. На первых порах так это наверно один из лучших способов переезда или постепенной перестройки мозга и архитектуры проекта.

    Лучшее из двух миров. Так многие поступают по моим наблюдениям.

    Оставлен 29 Октябрь 2009 в 15:56
  10. foxluck.ya.ru написал:

    Прозвучало.Несколько раз 'я верю'. Но мы же не религиозные фанатики.

    Лучше бы разобрал конкретный пример. решение какой-нибудь задачи двумя способами. couchdb и sql который бы послужил наглядным док-вом и лучшей основой для веры в новую технологию. ну или математическое обоснование couchdb или mongodb.

    а так показал sql монструозный и все. а может на couchdb все еще хуже. что и заметил один и слушателей.

    за sql стоит неплохой и простой математический аппарат. который в какой-то мере доказывает его работоспособность.

    прозвучало что типа вот академизм это плохо. но отсутствие вообще каких-либо оснований кроме веры в светлое будущее еще хуже.

    Оставлен 12 Ноябрь 2009 в 17:59
  11. Александр Кошелев написал:

    за sql стоит неплохой и простой математический аппарат. который в какой-то мере доказывает его работоспособность.

    Этот математический аппарат работает только в теории с бесконечно большой производительностью реализаций. На практике он не работает так же хорошо. В этом и проблема.

    Оставлен 12 Ноябрь 2009 в 21:18
  12. Сергей Шепелев написал:

    Про видео:

    1) завидую, что ты выступал перед живыми людьми :)

    2) противопоставляется SQL и нереляционные БД. Это не всегда правда. В Google AppEngine есть GQL для запросов к обёртке над BigTable. В общем случае, никто не мешает предоставить SQL-like синтаксис запросов к любой базе.

    3) противопоставляются нереляционные (или NoSQL? :) ) БД и надёжность хранения. Postgres до 7 версии буквально теряла и портила базы при холодном выключении. По-русски "целостность" близко и к durability и к consistency. В теории (то есть так чтоб у всех и обязательно), нереляционные БД не теряют ни того, ни другого. CouchDB, например, ну очень надёжная база. В смысле durability, она как раз подходит для хранения того, что нельзя потерять ни в каком случае. Целостностью в смысле consistency, многие новомодные базы жертвуют в пользу availability или partition-tolerance. Но это сознательный выбор. Нереляционное хранилище ещё не значит, что на нём нельзя построить БД поддерживающую целостность.

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

    "CouchDB ... неструктурированные документы" - бред, уж извините. :) Именно из-за хранения структурированных документов, вообще возможна работа с этими документами. Вот README в исходниках программы X это неструктурированный документ.

    Очень много говориться об удобстве, а доказательств нет.

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

    Этот "новый" способ хранения данных точно так же академичен и отягощён мильёном исследований. Просто другие исследования, другие академики работали. Без академичности только CSV получится.

    Оставлен 17 Ноябрь 2009 в 22:31
  13. Сергей Шепелев написал:

    Про CouchDB свежие новости, надеюсь, тебе понравится. Они сделали чекпоинты во время индексации. Теперь можно отлаживать новые вьюхи на большой базе. Запрос надо делать с ?stale=ok и будут отдавать текущее состояние индекса. Это всегда так работало, но недавно промежуточное состояние индекса стало периодически сохраняться. Фича начинается с 0.10.0.

    Оставлен 17 Ноябрь 2009 в 22:34
  14. Сергей Шепелев написал:

    Когда пытаются показать недостатки реляционных баз упускают один простой момент: они не масштабируются. Поскольку реляционная база пытается поддержать целостность (consistency) на 100% уровне, она не может работать более чем на одной машине. Master-slave реплики не в счёт, потому что не масштабируют запись. Нереляционная БД (в которой всё ещё может быть SQL, он не враг) это единственный на сегодня известный способ масштабировать запись. Ценой негарантированной или отложенной (eventual) целостности.

    Можно шардировать реляционную таблицу на N комьютеров и писать в них паралельно. Но это уже будет N таблиц, а не одна. Это уже не реляционная БД, потому что целостность связей между N таблицами ложится на плечи архитекторов.

    Оставлен 17 Ноябрь 2009 в 22:43
  15. Александр Кошелев написал:

    Сереж, ты мой посыл не очень понял. Давай я тебе отвечу отдельным постом, ок? Я думаю это будет интересно многим.

    Оставлен 18 Ноябрь 2009 в 14:42
  16. spiritofsim.livejournal.com написал:

    С хранением, записью и поиском по ключу все понятно. Подскажите, а как происходит поиск по сложным условиям?

    Оставлен 12 Август 2010 в 22:15
  17. Александр Кошелев написал:

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

    Оставлен 13 Август 2010 в 11:22
  18. spiritofsim.livejournal.com написал:

    А если нужно искать не по ключу, а по самим данным? В большинстве случаем именно так.

    Оставлен 19 Август 2010 в 18:10
  19. Александр Кошелев написал:

    Так, подождите. Говорим про CouchDB.

    У каждого документа есть ключ -- это его уникальный идентификатор.

    По нему можно искать как по точному совпадению так и по диапазону. Ключ это строка произвольного вида. От того как вы его сгенерите, зависит какие выборки можно делать.

    Дальше, в Кауче есть такое понятие как вьюхи -- это по сути индексы над документами. Не буду всё описывать, лишь скажу что вьюха может генерировать свои ключи и свои знаения по ним на базе атрибутов документов. Эти ключи могут быть произвольного формата и не только строки (например списки или дикты). По ним тоже можно икать строги, либо по диапазоном.

    Поэтому ключи документов и ключи вьюх позволяют достаточно гибкие делать выборки данных.

    Оставлен 20 Август 2010 в 00:02
  20. dima написал:

    Есть каталог. Есть много видов товаров. У каждого набор свойств, по которым юзер может отфильтровать нужное.

    На каждый товар - по таблице со свойствами + таблицы для связей M:M + таблицы для сложных свойств... Добавлять новые и модифицировать существующие таблицы, когда цвет коврика из описания решают перенести в свойства товара - большой геморрой.

    Начитался статей про CouchDB и решил что все свойства в одном документе решат мои проблемы, особенно с модификацией.

    Однако, энтузиазм быстро улетучился, когда оказалось что Map/Reduce в CouchDB - это очень ограниченная поделка.

    Например, нельзя было выбрать HDD, у которых производитель или Samsung или Western Digital. Ибо key-параметр поддерживает только одно значение. Для решения этой проблемы придумали затычку: в теле POST запроса передавать словарь вида {'keys': ['key1', 'key2']}.

    Но добавим в запрос фильтрацию по цене: от 1 до 100 и задача для CouchDB становится неразрешимой!!

    Элементарный запрос: бренд Western Digital или Samsung + цена до 100...


    Сейчас смотрю MongoDB. Сложные запросы умеет делать "из коробки", но пугает своей надежностью.

    Ибо из документации непонятно что выполняется атомарно - обновление всего объекта или только свойства :))

    Оставлен 23 Август 2010 в 05:41