Надежная карта для сопоставления с очередью для честного планирования?

Question

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

Теперь вот в чем проблема: запросам каждого клиента должен быть предоставлен равный приоритет по отношению к каждому ресурсу. То есть, если один клиент отправляет миллион запросов для определенного ресурса, а затем другой клиент отправляет дюжину сразу после этого, то второму клиенту не нужно ждать обработки запросов первого клиента, прежде чем они будут обработаны. Скорее, сначала должен быть обработан первый запрос одного клиента, а затем первый запрос другого, затем второй запрос первого и т. Д. Вперед и назад. (И аналогичная идея для более чем двух клиентов и нескольких ресурсов; кроме того, она может быть немного менее гранулированной, если эта базовая идея сохраняется).

Если бы это было достаточно мало, чтобы быть в памяти, у нас была бы просто карта ресурсов на карте от учетных записей к очереди запросов и круговая итерация учетных записей для каждого ресурса; но это не так, поэтому нам нужно решение на основе диска. Нам также нужно, чтобы он был надежным, высокодоступным, транзакционным и т. Д. . Какие у меня варианты? Я использую Java SE.

Заранее спасибо!

Answer 1

Заблаговременно я знаю HBase намного лучше, чем Кассандру. Некоторые аспекты моего ответа относятся к HBase, и я отмечу их как таковые.

Если вы предоставите достаточно оборудования, то реализация BigTable, такая как Cassandra или HBase, даст вам следующее:

1. Возможность хранить и получать ваши запросы с очень высокой скоростью
2. Способность поглощать удаления с чрезвычайно высокой скоростью (хотя с HBase и Cassandra очистка записи на диск может вызывать периодические задержки)

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

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

Еще одно потенциальное преимущество, которое вы, возможно, не учли, - это потенциальная возможность запуска ваших запросов непосредственно из узлов данных HBase или Cassandra, что избавляет вас от необходимости снова отправлять запрос по сети в процесс-исполнитель, чтобы фактически выполнить этот запрос. запрос. Возможно, вы захотите заглянуть в HBase Coprocessors или Cassandra Plugins , чтобы сделать что-то подобное. В частности, я говорю о превращении этого рабочего процесса:

                                 /-> Query -> Executor -> Resource -> Results -> \
Client -> Query -> Query Storage --> Query -> Executor -> Resource -> Results -> --> Client
                                 \-> Query -> Executor -> Resource -> Results -> /

в нечто вроде:

                                 /-> Query -> Resource -> Results -> \
Client -> Query -> Query Storage --> Query -> Resource -> Results -> --> Client
                                 \-> Query -> Resource -> Results -> /

Это может не иметь смысла в вашем случае использования.

Answer 2

Я могу дать вам несколько ответов относительно Кассандры.

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

Cassandra линейно масштабируется по многим узлам и не имеет единой точки отказа. Он линейно масштабируется как для чтения, так и для записи. Другими словами, один кластер может поддерживать любое количество одновременных операций чтения и записи, которые вы хотите выполнить, при условии, что вы добавите в кластер достаточно узлов и дадите кластеру время перебалансировать данные между новыми узлами. Netflix недавно проверила нагрузку Cassandra на EC2 и обнаружила линейную масштабируемость. Самый большой кластер, который они протестировали на 288 узлах, поддерживает 1 000 000 операций записи в секунду в течение часа.

Кассандра поддерживает много уровней согласованности . Выполняя каждое чтение или запись от Cassandra, вы указываете, с каким уровнем согласованности вы хотите, чтобы это чтение или запись выполнялись. Это позволяет вам определять для чтения и записи, должно ли это чтение или запись быть быстрым или должно выполняться последовательно на всех узлах, на которых размещается эта строка.

Cassandra не поддерживает многооперационные транзакции.

Если модель данных Cassandra хорошо работает в вашем случае, Cassandra вполне может быть самым простым решением, по крайней мере, на уровне операций. Каждый узел настроен точно так же. Нет хозяев и рабов, только равные. Нет необходимости настраивать отдельную балансировку нагрузки, отработку отказа, тактовые импульсы, доставку журналов, репликацию и т. Д.

Но единственный способ узнать наверняка - это проверить.