Потому что он считаешь хэш от запроса. Просто используйте параметризованные запросы, оформляйте их в одном стиле (без лишних пробелов, перечисление полей в одинаковом порядке и т.д.), и всё будет хорошо.
После того, как у них уволились оба два разработчика кассандры, они поняли, что поддерживать более-менее сложную конфигурацию без разработчиков слишком сложно, и перелили всё в хадуп. Говорили, что ну слишком большой порог вхождения.
О, забыл добавить про хадуп: он в мульти-ДЦ конфигурации не живёт вообще практически никак. В том же ФБ есть хитрожопая система горячего свапа неймноды, но это вариант для 2 ДЦ максимум, и ещё качественный канал между ними нужен.
Собственно, я почему так расспрашивал: один разраб из фейсбука на прошлогоднем YaC пол дня с нами тусил. Он рассказал нам страшную историю о том, почему они перестали использовать кассандру :)
Правда, у них по сравнению с автором поста несколько нечестные условия: всего 2 ДЦ, и оба в штатах.
Хотелось бы немного подробностей.
Почему именно кассандра? От неё отказались в фейсбуке и, на сколько я знаю, отказываются (или уже отказались) в твиттере.
Какой replication factor? Пишете/читаете с кворумом?
Сталкивались с проблемой потери данных в случае hinted handoff и потери ещё одной машины?
Ну и вообще, сколько у вас примерно данных в целом, сколько дисков в штуках, сколько памяти, и сколько запросов в секунду, это самые интересные цифирки.
С квартирой вы несколько мимо щас :) Недвижимость в Калифорнии ой какая дорогая. С машиной тоже не так однозначно: в Москве, например, можно без машины легко прожить, в Штатах почти в любом городе кроме NY вам скорее всего понадобится 2 машины на семью.
Тогда уж более верное сравнение владелец мини-сервиса в Москве и механик F1 :) И тут возникает вопрос, а чего человек в детстве то хотел, самые быстрые в мире болиды проектировать/собирать, или заниматься административной работой, пусть и в своём собственном сервисе.
Линейная запись на диск чуть ли не на порядок быстрее случайной, так что тут можно получить какой-то профит от писания только Write-Ahead лога. Довольно большой буфер может сглаживать пиковые нагрузки. Но что-то мне подсказывает, что InnoDB при грамотной настройке будет работать не сильно хуже, если не лучше.
Я внимательно читал. Если есть техническая возможность использовать 10G — то надо её использовать. Нынче 10G не такая уж редкость, встречается всё чаще и чаще.
Если в таком контексте — то вам нужен CDN свой. Ставьте по машинке у каждого крупного провайдера из интересующих регионов, каждая из них будет хватать поток с вашего телеканала и вещать локально. Если провайдер достаточно крупный — то он может предложить вам и 10G до своего ядра. Ну и 1 машинку в Москве, на неё будут ходить из тех провайдеров, которые не согласились у себя поставить ваши региональные машины.
На сколько я вижу из поста, автор смог выжать 2.5 гигабита с одного ядра, так что смысл есть.
А с синхронизацией в кольцевом буфере особо проблем нету. Если сделать буфер на, к примеру, 1 минуту, кто клиент, который отстал на 1 минуту от паблишера, принудительно отключается. Даже локи не нужны, надо только «оборот» кольца хранить и делать небольшую зону от хвоста, куда нельзя залезать (чтобы паблишер не записал туда новый код, пока клиенту отдаются данные). Ваш код пристально не смотрел, но должна быть похожая схема с ограничением длины буферов, чтобы память не выжирать.
Сейчас работает только в 1 воркере потому, что буфер хранится в локальной памяти? Если в shared память запихнуть кольцевой буфер и из него клиентам отдавать контент — то должно неплохо работать с любым количеством воркеров. В нгинксе есть все нужные обёртки для работы с shared memory, используются в ngx_http_file_cache.c.
А вы свои ответственные сервисы только в одном ДЦ хостите что ли? Хорошо спроектированному сервису потеря одного ДЦ не должна нанести урона, разве что производительность немного упадёт. Сам Амазон вот точно про это знает :)
Из тех, что в том же Фейсбуке или Твиттере платят $120k-$140k в год, а в Москве $100k — это после вычета всяких налогов получится больше 150к рублей на руки в месяц — более чем хорошая зарплата для программиста (не менеджера проектов и, пожалуй, чуть выше средней для груплида).
Вы же не думаете, что в том же Яндексе программисты будут в среднем хуже, чем в Фейсбуке? Цифры смотрите чуть выше, дальше решайте сами.
Вот только в Москве потратив $100к на зарплату (включая все налоги) вы получите намного более квалифицированного специалиста, чем в долине. Да даже и не в долине тоже.
Правда, у них по сравнению с автором поста несколько нечестные условия: всего 2 ДЦ, и оба в штатах.
Почему именно кассандра? От неё отказались в фейсбуке и, на сколько я знаю, отказываются (или уже отказались) в твиттере.
Какой replication factor? Пишете/читаете с кворумом?
Сталкивались с проблемой потери данных в случае hinted handoff и потери ещё одной машины?
Ну и вообще, сколько у вас примерно данных в целом, сколько дисков в штуках, сколько памяти, и сколько запросов в секунду, это самые интересные цифирки.
В общем, велосипед, который давно написали :)
А с синхронизацией в кольцевом буфере особо проблем нету. Если сделать буфер на, к примеру, 1 минуту, кто клиент, который отстал на 1 минуту от паблишера, принудительно отключается. Даже локи не нужны, надо только «оборот» кольца хранить и делать небольшую зону от хвоста, куда нельзя залезать (чтобы паблишер не записал туда новый код, пока клиенту отдаются данные). Ваш код пристально не смотрел, но должна быть похожая схема с ограничением длины буферов, чтобы память не выжирать.
А ДЦ падали, падают и будут падать, это аксиома.
Выберете место, где вам хотелось бы жить, и посмотрите зарплаты на www.glassdoor.com
Вы же не думаете, что в том же Яндексе программисты будут в среднем хуже, чем в Фейсбуке? Цифры смотрите чуть выше, дальше решайте сами.