Pull to refresh

Comments 23

Чуваки из Digg вообще прогрессивные красавцы, уже давно слежу за их нововведениями и решениями.
Кассандра сильная вещь, надо будет в продакшене попробывать.
Попробывал.

1. Нагрузку на слабых машинах не держит.
2. Supercolumn Penalty, про которое я не нашел в статье ( а выделить это надо было красными буквами) Привело к тому, что касси гоняла от HDD до оперативы по 2-3 гб в нагруженных участках.
3. Переписывание на колонки не помогло — нагрузка спала на 30-40% ( т.е. с 40,8 до 34,5) Но все равно нас это не спасло.
4. Касссандра — сидльное решение для сильных кластеров. На своем корпоративном CoreQuad, на котором еще крутятся и Ваши интранетовые вещи тестировать не советую.

Например, на канале #cassandra средняя конфигурация, где ее используют — 8-ми нодовый, 16 ядер на нод и по 4 HDD на RAID1. Если Вы собираетесь масштабировать такие мощности, то «тормознутость» касси уходит на второй план, т.к. масштабировать ее очень легко — и в случае большого числа реплик работает она просто отлично, но ее привычка гонять от оперативы до жесткого неимоверные количества данных просто раздражают.
По смыслу идея аналогична той, что используется гуглом в его Datastore для App Engine: code.google.com/appengine/docs/python/datastore/
Терминология только отличается.

А за перевод спасибо — взгляд несколько с другой стороны был полезен.
Всегда пожалуйста =)

Думаю, что различия есть, вот навскидку, например, «Интерфейс хранилища данных обладает большинством функций обычных баз данных». В Cassandra это уж точно не так, и думаю, других различий множество.

Что лучше, а что хуже — этого я сказать не могу, но могу упомянуть, что Cassandra, по моим сведениям, используется на фейсбуке и в твиттере.
Ну это Google слегка покривил душой, чтобы не очень пугать народ, который отважится что-то писать под GAE ;)

На самом деле там есть настоящий «язык» запросов:
code.google.com/appengine/docs/python/datastore/queryclass.html#Query_filter

и есть надстройка над ним, которая называется GQL:
code.google.com/appengine/docs/python/datastore/gqlreference.html

GQL похож на SQL чисто условно. Скажем SELECT там всегда «SELECT *», естественно никаких JOIN'ов, COUNT'ов и т.п, в WHERE разрешен фактически только AND и IN, и много-много других ограничений диктуемых принципом хранения и выборки.
Я, ради любопытства, написал под GAE одно небольшое приложение. Это конечно возможно, но подходы принципиально другие. Навыки работы с реляционными базами оказываются скорее вредны, об огромном количестве вещей надо волноваться заранее — потом уже ничего не изменишь. Хочется статистики — изволь вести все необходимые счётчики в процессе записи данных. Короче говоря, есть области применений, куда эти реляционные БД удачно вписываются, но их не так много, по ощущениям.

В фейсбуке mysql, а в твиттере (погуглив) — да, пишут что вроде собираются переходить на cassandra'у.
Но в твиттере-то структура базы не такая сложная, а вот фейсбуку уйти от реляционных баз будет ой как не просто. Особенно с его любовью к громоздким страничкам с кучей разной взаимосвязанной информации из БД.
Одна тонкость про фейсбук: именно они авторы Касандры
А можете прислать пруфлинк? Я за 3 минуты гугления не нашел никаких ссылок на то, что фейсбук разрабатывал кассандру.
Взаимосвязанную информацию в кассандре организовать можно, и очень хорошо… если вы читали статью, могли бы заметить =) другое дело, что выборок делается очень много, в MySQL информацию можно забрать парой запросов, тогда как в кассандре придётся множество записей выбирать поштучно. Но на больших проектах кассандра всё равно выигрывает у MySQL за счёт неограниченной горизонтальной масштабируемости. Насчёт других баз данных сложно сказать, я с ними не работал.

И насчёт фейсбука splix прав, у меня просто нет пруфлинка.
А что то там всего порядка 200 коммитов. Она ли это
В фейсбуке cassandra используется только для поиска по личных сообщениях. А что-то ещё они вроде как и не собираются переводить на неё.
Немного дополню. В твиттере, если верить статье на highscalability, Cassandra используется для геолокации и аналитики. Переходить на хранение твитов в кассандре они пока не решились.
Ryan King says: This is a change in strategy. Instead we’re going to continue to maintain our existing Mysql-based storage. We believe that this isn’t the time to make large scale migration to a new technology.
Пару недель назад в список рассылки разработчиков вошёл некий bikeshed с предложением полностью новой схемы именования для разрешения неразберихи.

Пару недель назад в списке рассылки разработчиков шёл процесс bikeshed-а на тему полностью новой схемы именования для разрешения неразберихи.
Такое ощущение что писали для дибилов… об элементарных вещах пишут так как будто это Квантовая механика для домохозяек.
согласен, разжевали по-полной… много повторений, сам бы я написал намного лаконичнее… но с другой стороны, кто знает, может так лучше усваивается?
Если не усвоилось с первого раза, человек может прочесть второй раз. Наоборот хуже, чем лаконичнее тем лучше усваивается.
UFO landed and left these words here
Замечательное введение.

Проектируй я рассматриваемую схему, я бы точно вместо «волшебного значения» "__notag__" использовал пустую строку: и нагляднее суть «тэга нет», и места не занимает.
Only those users with full accounts are able to leave comments. Log in, please.