Comments 67
> Движение NoSQL это не движение против реляционных баз данных.
> NoSQL — это «Не только SQL» (Not Only SQL), а не «Нет SQL» (No SQL at all).
Тогда разумнее записывать эту аббревиатуру как NOSQL.
> NoSQL — это «Не только SQL» (Not Only SQL), а не «Нет SQL» (No SQL at all).
Тогда разумнее записывать эту аббревиатуру как NOSQL.
Возможно, но уже как-то принято писать именно так — en.wikipedia.org/wiki/NoSQL
Хороший краткий обзор, спасибо.
Жаль, что Эванс своим предложением хранить моделей предметной области не в РСУБД нажил себе врагов — как среди читателей книг-приверженцев реляционизма :) Это сразу сузило его аудиторию. Радует то, что таких остается все меньше и меньше.
Жаль, что Эванс своим предложением хранить моделей предметной области не в РСУБД нажил себе врагов — как среди читателей книг-приверженцев реляционизма :) Это сразу сузило его аудиторию. Радует то, что таких остается все меньше и меньше.
Их потихоньку убирают?
:)
Не, до них потихоньку доходит, что не SQLем единым живы данные. Ну и естественный процесс помогает — зоказчег часто понимает, что ему нужно как можно более подходящее решение, а не «о, у вендора X есть отличная РСУБД, запилим на ней» отсылка к дедам-авторитетам, что мы «всю жись на foxpro рубили, SQL рулит и бибикает»
Не, до них потихоньку доходит, что не SQLем единым живы данные. Ну и естественный процесс помогает — зоказчег часто понимает, что ему нужно как можно более подходящее решение, а не «о, у вендора X есть отличная РСУБД, запилим на ней» отсылка к дедам-авторитетам, что мы «всю жись на foxpro рубили, SQL рулит и бибикает»
Хороший вариант хранилищ данных для онлайновых браузерных игр в реалтайме, баннерных систем и тому подобного.
в js-kit.com используется файловая система для хранения информации
Вы случаем не из этой компании? Интересно было бы увидеть обзор и какие хранилища используются при их объемах данных, так сказать из первых рук =)
Кое какая информация есть тут — lionet.livejournal.com/, но её мало.
Кое какая информация есть тут — lionet.livejournal.com/, но её мало.
работал там. насколько я помню, обычная фс. выборка данных идёт по пути к файлу. всё гениальное — просто.
насчёт вопроса железа, не знаю.
насчёт вопроса железа, не знаю.
Периодически пользуюсь аналогичной схемой. Но при первой возможности отказываюсь.
Основной минус — сильно ест диск. Если много небольших блоков данных — приличный объем съедается впустую.
Удобство — когда постоянно нужно модифицировать отдельные блоки. В одном проекте перешел на файлы, дисковые расходы терплю, пока не нашел достойной альтернативы.
В другом проекте, где несколько индексов ежедневно обновлялись целиком и по-новой разворачивались в кучу мелких файлов ушел от кучи к одному большому файлу с индексом. Сэкономил не только диск, но и время развертывания данных.
Основной минус — сильно ест диск. Если много небольших блоков данных — приличный объем съедается впустую.
Удобство — когда постоянно нужно модифицировать отдельные блоки. В одном проекте перешел на файлы, дисковые расходы терплю, пока не нашел достойной альтернативы.
В другом проекте, где несколько индексов ежедневно обновлялись целиком и по-новой разворачивались в кучу мелких файлов ушел от кучи к одному большому файлу с индексом. Сэкономил не только диск, но и время развертывания данных.
>Интересным вариантом является использование в CouchDB B-деревьев, только с функцией добавления (append-only B-Trees), что позволяет избежать накладных расходов на позиционировании головки.
тут больше скорости при записи изза того что не нужно перестраивать индекс, а не изза головки которая и так ездиет за шелскриптами/апачами (if any), etc
Ну и сама фраза несколько не понятно написана, AoBT — бинарное дерево которое не нужно перестраивать при добавлении элементов. соответственно в CouchDB элементы не удаляются, лишь добавляются записи об удалении, что поидее должно хорошо сказываться на перформансе при записи :)
тут больше скорости при записи изза того что не нужно перестраивать индекс, а не изза головки которая и так ездиет за шелскриптами/апачами (if any), etc
Ну и сама фраза несколько не понятно написана, AoBT — бинарное дерево которое не нужно перестраивать при добавлении элементов. соответственно в CouchDB элементы не удаляются, лишь добавляются записи об удалении, что поидее должно хорошо сказываться на перформансе при записи :)
Хотелось бы почитать про стабильность упомянутых решений.
А то есть негативный опыт с repcached — так и не удалось добиться стабильной работы на солярисе.
А то есть негативный опыт с repcached — так и не удалось добиться стабильной работы на солярисе.
Честно сказать, я тоже. Дело в том, что эти системы достаточны молодые и из них работает в большом продакшене только одна — Cassandra (используется на Facebook для хранения индекса для поиска по входящим сообщениям). Но если я найду исследования по стабильности других решений, конечно же выложу.
CouchDB полностью защищена от поломки базы, там даже нет отдельной команды для выключения сервиса, его убивают kill`ом :) Т.е. на диске при любых условиях целостная база
MongoDB наоборот, требует специального шатдауна, и при аварийном завершении нужно чинить базу, в результате чего могут полаться OID объектов и сломать связи между объектами если вы их используете. Сответсвенно авторы советуют для защиты базы использовать кластер из >1 интсанса монго.
MongoDB наоборот, требует специального шатдауна, и при аварийном завершении нужно чинить базу, в результате чего могут полаться OID объектов и сломать связи между объектами если вы их используете. Сответсвенно авторы советуют для защиты базы использовать кластер из >1 интсанса монго.
Кластеры вообще-то штука требующая достаточно высокой квалификации и опыта работы с ней.
И уж тем более следует относится с недоверием к кластерам из нового, не испытанного годами большого продакшна, софта. Особенно в горизонтально масштабирующихся системах.
Причем потеря данных — это лишь одна из угроз. Нужно еще поизучать, насколько софт терпим к потерям в сети, выходам из строя и временным выпадениям отдельных узлов, а в наших условиях еще и к неожиданному отключению всего кластера по питанию.
И уж тем более следует относится с недоверием к кластерам из нового, не испытанного годами большого продакшна, софта. Особенно в горизонтально масштабирующихся системах.
Причем потеря данных — это лишь одна из угроз. Нужно еще поизучать, насколько софт терпим к потерям в сети, выходам из строя и временным выпадениям отдельных узлов, а в наших условиях еще и к неожиданному отключению всего кластера по питанию.
дада, с couch это by design так
For higher availability and more concurrent users, CouchDB is designed for “shared nothing” clustering. In a “shared nothing” cluster, each machine is independent and replicates data with its cluster mates, allowing individual server failures with zero downtime. And because consistency scans and fix-ups aren’t needed on restart, if the entire cluster fails – due to a power outage in a datacenter, for example – the entire CouchDB distributed system becomes immediately available after a restart.
хабра схела копипасту :)
Кассандра — вполне стабильна. Думаю, через пару месяцев напишем на хабре подробнее, как будут весомые нагрузки. А пока что полет более чем нормальный на тестах.
Neo4J чем-то напомнил Cerebrum( www.shuklin.com/ai/ht/ru/cerebrum/ )
представление данных, имхо, очень удобно хранить в графовых структурах, поскольку именно этот способ очень схож с устройством человеческой памяти, подходит для тэгирования и категоризации данных, хранения знаний. вообще не понимаю, почему такие системы не развивались как альтернатива sql.
Хотелось бы отметить, что Redis поддерждивает репликацию.
Немного не понял про масштабируемость Redis — вроде читал, что такая классная и быстрая, масштабируемая система, а тут оказывается не так. Можете прокомментировать немного подробнее?
И еще про возможность потери данных в Redis — он хранит большое количество данных для записи долгое время?
Учитывая его асинхронную работу с файловой системой, мне кажется вполне возможно, что записывает он очень часто и даже при непредвиденном сбое может потеряться минимум данных. Да и то, такие сбои, что сервер не успеет записать данные, мне кажется, довольно редки.
И еще про возможность потери данных в Redis — он хранит большое количество данных для записи долгое время?
Учитывая его асинхронную работу с файловой системой, мне кажется вполне возможно, что записывает он очень часто и даже при непредвиденном сбое может потеряться минимум данных. Да и то, такие сбои, что сервер не успеет записать данные, мне кажется, довольно редки.
Конечно могу. Тут не сказано, что Redis не такая как вы сказали. Redis как написано в третьей таблице использует для хранения оперативную память с периодическими снэпшотами которые записываются на диск, и есть возможность, что вы запишите в систему данные которые вы потеряете в случае сбоя или отключения питания — снэпшот не будет сохранен.
Да, хранит. Как я уже сказал используются снэпшоты памяти. Потеря данных, вне зависимости от количества — это плохо. Например очень большие объемы данных в банковском секторе, согласитесь, вы бы не хотели, чтобы система потеряла пару нолей в вашем счету?
Все зависит от объема данных. А если их много, и нужна минимальная потеря данных, для меня предпочтительней идеи BigTable и Cassandara с Memtable и SSTable.
Да, хранит. Как я уже сказал используются снэпшоты памяти. Потеря данных, вне зависимости от количества — это плохо. Например очень большие объемы данных в банковском секторе, согласитесь, вы бы не хотели, чтобы система потеряла пару нолей в вашем счету?
… мне кажется вполне возможно, что записывает он очень часто...
Все зависит от объема данных. А если их много, и нужна минимальная потеря данных, для меня предпочтительней идеи BigTable и Cassandara с Memtable и SSTable.
там еще есть append.log который постоянно писаться может и сбрасываться на диск после каждой записи. ПРи восстановлении можно по логу восстановиться вместо снапшота.
Понял, спасибо.
Создатели самого Редиса прямо не рекомендуют на данный момент использовать эту систему в секторах, где потеря небольшого количества недавних изменений данных критична.
Точнее, не рекомендовали. Новая фича — append-only log — позволяет восстанавливать все данные после сбоя. Хотя, справедливости ради надо отметить, использование этой возможности требует много места на диске, и, кроме того, в «самом надежном» режиме она плохо сказывается на производительности. Здесь можно посмотреть кое-какие тесты: www.mysqlperformanceblog.com/2009/12/10/redis-benchmarks-on-fusionio-round-1/
Так же интересно отметить, что можно настроить как часто «Редиска» сбрасывает кэш на диск. В текущей реализации сделана комплексная проверка — снэпшот каждые ХХ секунд при наличии УУ операций с базой. Таких «лимитов-условий» можно завать целый список.
UFO just landed and posted this here
Информация о Redis в табличке несколько устарела. Действительно, Redis поддерживает репликацию данных (Master-Slave).
Некоторые проблемы с масштабируемостью пока есть, и раскидать данные по множеству серверов без бубна не получится. Это связано с тем, что некоторые операции работают с несколькими ключами сразу (например, тип данных set поддерживает операции union, difference, intersection; sort может сортировать данные не в алфавитном порядке, а используя список «весовых» значений, хранящихся по другому ключу; атомарная операция msetnx может устанавливать значения сразу для множества ключей; и т.п.). Такие операции (пока) невозможны, если ключи хранятся на разных серверах. Автор обещает внедрить поддержку Redis-Cluster в будущих версиях, тогда эта проблема будет решена.
Что касается сохранности данных и записи их на жесткий диск, уже сейчас реализована такая фича как append-only log: в фоновом режиме Redis может сохранять историю всех изменений данных. В случае сбоя по этому логу можно восстановить все потерянные данные.
Некоторые проблемы с масштабируемостью пока есть, и раскидать данные по множеству серверов без бубна не получится. Это связано с тем, что некоторые операции работают с несколькими ключами сразу (например, тип данных set поддерживает операции union, difference, intersection; sort может сортировать данные не в алфавитном порядке, а используя список «весовых» значений, хранящихся по другому ключу; атомарная операция msetnx может устанавливать значения сразу для множества ключей; и т.п.). Такие операции (пока) невозможны, если ключи хранятся на разных серверах. Автор обещает внедрить поддержку Redis-Cluster в будущих версиях, тогда эта проблема будет решена.
Что касается сохранности данных и записи их на жесткий диск, уже сейчас реализована такая фича как append-only log: в фоновом режиме Redis может сохранять историю всех изменений данных. В случае сбоя по этому логу можно восстановить все потерянные данные.
Думаю автору стоит дополнить пост полученной от вас информацией.
Какой именно? В статье нет информации о том, что Redis не поддерживает репликацию. К тому же пока репликация не очень стабильно работает судя по словам birukoff и количеству задач связанных с репликацией на странице проекта на code.google.com.
Фича с append-only log добавлена только в версии 1.1, которая на данный момент находится в стадии beta, поэтому фича и не упомянута в статье.
Фича с append-only log добавлена только в версии 1.1, которая на данный момент находится в стадии beta, поэтому фича и не упомянута в статье.
Последние тесты Redis с append-only log
www.mysqlperformanceblog.com/2009/12/10/redis-benchmarks-on-fusionio-round-1/
www.mysqlperformanceblog.com/2009/12/10/redis-benchmarks-on-fusionio-round-1/
Обзор интересный. Вообще по моему мнению NoSQL будет и дальше набирать обороты, нужно только популизировать его.
К пример — системы статистики, аггрегаторы — это идеальный вариант для них.
Также в статье можно указать на ссылку на сам блог — www.rackspacecloud.com/blog/category/development/ и статью — www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/. Действительно увлекательное чтиво, периодически появляются шикарные статьи.
К пример — системы статистики, аггрегаторы — это идеальный вариант для них.
Также в статье можно указать на ссылку на сам блог — www.rackspacecloud.com/blog/category/development/ и статью — www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/. Действительно увлекательное чтиво, периодически появляются шикарные статьи.
После прочтения этой статьи, вашу прошлую о Riak было читать особенно интересно.
А про Berkeley DB почему не упомянули?
Все перечисленные вместе имеют меньше инсталляций чем она одна :-)
Все перечисленные вместе имеют меньше инсталляций чем она одна :-)
Огромное спасибо… обзор на высоте!
Статья отличная!
А насчёт нереляционных баз, так они ещё старше чем реляционные.
Да, несомненно, у хешей и B-tree скорость отличная.
Однако создавая более менее сложную систему вы неприменимо придёте к реляционности.
Вот посмотрите пример создание клона Twitter на Redis, уже с первых строк пошла реляционность, конечно это потому что такая задача, но ведь большинство именно таких.
А поиск по разным полям?
Тут конечно документо-ориентированные базы рулят по сравнению с простыми ключ-значение,
но в них появляется надобность создавать индексы =)
В общем, нереляционные базы быстры, но они не панацея, и следует обдумано подходить к вопросу, даже не смотря что это так модно нынче.
А насчёт нереляционных баз, так они ещё старше чем реляционные.
Да, несомненно, у хешей и B-tree скорость отличная.
Однако создавая более менее сложную систему вы неприменимо придёте к реляционности.
Вот посмотрите пример создание клона Twitter на Redis, уже с первых строк пошла реляционность, конечно это потому что такая задача, но ведь большинство именно таких.
А поиск по разным полям?
Тут конечно документо-ориентированные базы рулят по сравнению с простыми ключ-значение,
но в них появляется надобность создавать индексы =)
В общем, нереляционные базы быстры, но они не панацея, и следует обдумано подходить к вопросу, даже не смотря что это так модно нынче.
Основной проблемой является то, что реляционные базы данных не могут справляться с нагрузками актуальными в наше время (мы говорим о high-load проектах) — Ларри Элиссон плачет каждый раз, когда Вы это говорите :)
Кстати, а он миллиард баксов так ведь и не проиграл? Его никто не уделал на Hi-load проектах? А?
Кстати, а он миллиард баксов так ведь и не проиграл? Его никто не уделал на Hi-load проектах? А?
А где Mnesia?
В этой статье не рассматривались встраиваемые СУБД. Mnesia и Berkeley DB именно к такому типу и относятся.
Брррр Berkeley DB — встраиваемая????
Вы шутите. Наличие слова «embeddable» на главной странице говорит только о том, что ее можно встраивать, а не о том, что только встраивать.
Она более полноценная БД чем многие из обзора. К примеру поддержка репликации мастер-мастер.
Вы шутите. Наличие слова «embeddable» на главной странице говорит только о том, что ее можно встраивать, а не о том, что только встраивать.
Она более полноценная БД чем многие из обзора. К примеру поддержка репликации мастер-мастер.
Да, возможно я ошибся, так как мало знаком с данной базой данных. В описании к Berkeley DB написано:
Насколько я понимаю этот текст, для организации структуры для хранения больших объемов данных и распределенной структуры которая необходима для этого, нам придется самим дописывать поверх системы дополнительный функционал.
Основные цели систем приведенных в статье — работа с большими объемами данных и высокой нагрузкой. Примеров high-load проектов с использованием Berkeley DB как основного хранилища, я не нашел. Если вы приведете ссылки на такие проекты, я был бы крайне признателен.
For example, like SQLite, it does not provide support for network access — programs access the database using in-process API calls.
Насколько я понимаю этот текст, для организации структуры для хранения больших объемов данных и распределенной структуры которая необходима для этого, нам придется самим дописывать поверх системы дополнительный функционал.
Основные цели систем приведенных в статье — работа с большими объемами данных и высокой нагрузкой. Примеров high-load проектов с использованием Berkeley DB как основного хранилища, я не нашел. Если вы приведете ссылки на такие проекты, я был бы крайне признателен.
Пожалуй был не совсем прав.
Просто в свое время рассматривалась возможность ее использования и нашлись разработки для доступа к ней по сети.
Отказались по причине снижения требований к надежности хранения данных.
По памяти нашлось только это
www.interface.ru/home.asp?artId=19187
В принципе ничто не мешает организовать собственный типа сервер доступа. API у Berkeley DB очень пристойное. Транзакции и развод кроликов при паралельном доступе реализованы там достаточно неплохо.
Естественно затраты на разработку резко растут. Смысл имеет если Вам необходимо максимально надежное хранилище при очень высокой производительности.
Мы остановились на Tokyo Cabinet.
По большому счету Tokyo Tyrant является прокладкой для доступа из сети к Tokyo Cabinet.
Чем подкупил Tokyo Cabinet, так это возможностью выбора режима. Если мне нестрашно потерять какие то из последних данных — могу его разогнать как ракету, если небходима надежность — за счет производительности имею ее.
Как то комфортней себя чувствую если сам подобными вещами рулю :-)
Просто в свое время рассматривалась возможность ее использования и нашлись разработки для доступа к ней по сети.
Отказались по причине снижения требований к надежности хранения данных.
По памяти нашлось только это
www.interface.ru/home.asp?artId=19187
В принципе ничто не мешает организовать собственный типа сервер доступа. API у Berkeley DB очень пристойное. Транзакции и развод кроликов при паралельном доступе реализованы там достаточно неплохо.
Естественно затраты на разработку резко растут. Смысл имеет если Вам необходимо максимально надежное хранилище при очень высокой производительности.
Мы остановились на Tokyo Cabinet.
По большому счету Tokyo Tyrant является прокладкой для доступа из сети к Tokyo Cabinet.
Чем подкупил Tokyo Cabinet, так это возможностью выбора режима. Если мне нестрашно потерять какие то из последних данных — могу его разогнать как ракету, если небходима надежность — за счет производительности имею ее.
Как то комфортней себя чувствую если сам подобными вещами рулю :-)
tokyo cabinet встраиваемая
Парадокс :-)
Тема NoSQL.
Если залезть в потроха MySQL Cluster увидите — там в основе обычное хранилище key-value :-)
На него навернуты масштабируемость, поддержка надежности, доступ на языке SQL со всеми вытекающими последствиями для производительности.
Если посмотреть производительность — все как и во всех key-value, ракета по получению key-value, задница при каком нибудь join'е.
В принципе, конечной точкой навертывания функционала на перечисленные в статье системы нечто подобное и является.
По сути все они — промежуточные точки между memcached и чем то подобным MySQL Cluster.
Тема NoSQL.
Если залезть в потроха MySQL Cluster увидите — там в основе обычное хранилище key-value :-)
На него навернуты масштабируемость, поддержка надежности, доступ на языке SQL со всеми вытекающими последствиями для производительности.
Если посмотреть производительность — все как и во всех key-value, ракета по получению key-value, задница при каком нибудь join'е.
В принципе, конечной точкой навертывания функционала на перечисленные в статье системы нечто подобное и является.
По сути все они — промежуточные точки между memcached и чем то подобным MySQL Cluster.
redis умеет append-only
tokyo cabinet умеет + table и fixed length string в on-disk и hash и b-tree (кстати очень хорошо настраиваемые) в on-memory
кроме того используя скрипты lua можно легко смастерить еще модели, коллекции, например, как в редисе
tokyo cabinet умеет + table и fixed length string в on-disk и hash и b-tree (кстати очень хорошо настраиваемые) в on-memory
кроме того используя скрипты lua можно легко смастерить еще модели, коллекции, например, как в редисе
А почему нет указания что эта статья перевод?
Есть еще такая СУБД как InterSystems Caché. На их сайте написано, что она «World's fastest object database». Впрочем на больших объемах проверять не приходилось. Используется исторически в медицинских учреждениях.
маленькая поправочка: Tokyo Cabinet. не является распределенной БД, это всего лишь АПИ к разного вида key/value таблиц. источник fallabs.com/tokyocabinet/
на базе Токио можно уже построить что-то своё.
на базе Токио можно уже построить что-то своё.
Sign up to leave a comment.
Обзор NoSQL систем