Меня тут в твитере спросили почему я советую использовать в случае использования NOSQL Riak и Cassandra. Скажу о каждой:
Riak — офигенна. Во первых это p2p система, ее разрабатывают люди которые работали над Amazon Dynamo. То есть управляющего сервера нет как такового. Это очень отличный ход в сторону fault tolerance, так как обычно именно управляющий сервер является слабым звеном во всей системе. Вторая мега фича, это разрешение вопросов с целостностью данных, когда на 2 кластерах есть 2 разные версии одного документа (может произойти в случае отсутвия связи между кластерами). В большинстве случаем, система сама разрулит ситуацию, если нет, дает функционал для написания своих правил обработки ситуаций. Еще 2 вкусняшки — это map reduce и ссылки. И ссылки самое вкусное. Возможно ссылаться из одного документа на другой, это же круто, это легко и понятно. И да да, Riak это документоориентированное хранилище. Хотя оно позиционируется как key/value над key/value функционалом, есть специальная прослойка для работы как с документами. Минус — она на Erlang, починить в случае бага, большинству будет трудно (хотя я стал вникать в эрланг именно благодаря этому проекту). К тому же для больших корпораций важна поддержка продукта, ребята из Basho за $ ее вам обеспечат, кругласуточно при чем выяснять ваши проблему будут разработчики.
Теперь о Cassandra — это еще более офигенная система вплане архитектуры. Ее архитектура берет корни из Amazon Dynamo (P2P как Riak) и BigTable, а как вы знаете BigTable это то на чем крутиться процентов 98 гугла. В принципе архитектура почти полностью повторяет column-family структру базы, но добавляя в нее supercolumns (чтоб было понятнее — в MySQL это было бы наборы таблиц). Но самое крутое — это система записи даных. При поступлении запроса на запись, данные вначале записываются в disk commit log (на случай сбоя, чтобы можно было обработать данную ситуацию в дальнейшем), после этого даные записываются в memtable, иначе говоря в память. Когда memtable набирает достаточное количество записей (ситуаций 3 — достигается лимит используемомй памяти, уже получено 128 записей, или просто подошло время сохранить данные — каждые n секунд данные сохраняются на диск), она записывается на диск в виде уже SSTable и создается индекс SSTable Index. После чего disk commit log удаляется. Как говорят сами разрабочики это дает им:
— No reads
— No seeks
— Fast
— Atomic within ColumnFamily
— Always writable
Ну а если это не понятно, просто сравним скорость записи и чтения между Cassandra и MySQL:
MySQL — Чтение: ~350ms Запись: ~300ms
Cassandra — Чтение: ~15ms Запись: ~0.12ms
То есть такая система, с кэшированием записей прежде чем записать их на диск, дает очень существенный прирост в скорости.
Я описал только Power Features этих проектов. У них есть и минусы и плюсы, некоторые системы их операжают по некоторым параметрам, но в общем, как готовый продукт, именно эти 2 системы я считаю лучшими на данный момент, для проектов с большими объемами данных.
К тому же как человек, работающий с NoSQL и изучающий его возможности скажу — самое трудное это начать мыслить иначе, чем вы привыкли, уйти от таблиц, join'ов и всего прочего. Это реально очень трудно.
#591036
from Talk.v10428D73BDB,
23 months agoRecommended by (1): @nirthfurzahad