Redis ограничивает длину битового поля в 512 мегабайт. Все реализации, которые я смог найти (1, 2) рассчитаны на использование только одного ключа Redis. Это ограничивает размер фильтра.
Почему бы просто не запатчить redis с целью поддержки более длинных битовых полей?
На данный момент эти библиотеки есть не для всех языков и платформ разработки.
Для redis есть http_api, например такое. Можно поставить его и написать процедуру на lua в которой будет вся логика.
HTTP намного более громоздкий чем родной redis-а, соотвественно часть времени будет тратится на парсинг и формирования запросов.
Ну и самое главное:
1) В redis есть журнал операций — соотвественно если инстанс редиса прибить он восстановит из журнала все последние записи. В вашем случае могут потерятся записи за последние 300 секунд.
2) В redis имеется репликация, если один инстанс ляжет — приложение может сходить в другой.
Ну а так вроде всё норм, только ещё бы batch запросы добавить.
Да, шифрование и авторизация — нужная фича, в одной из следующих версий обязательно добавим. Сейчас у нас оно запускается во внутренней сети, поэтому сразу и не сделали.
обновленные воркеры не могут получать задания, пока их не станет большинство
В текущем виде они вполне себе успешно получат задания, но из за того что логика старых и новых воркеров разная — в лучшем случае старые воркеры покрешатся из за того что дернется к примеру не существующий метод — в худшем — разъедутся данные из за отличий в реализации таких-же методов.
Это очень похоже на то, что описано в статье: Реплицируемый объект. Только там я использовал С++ и другой алгоритм консенсуса.
Отчасти я вашей статьёй и вдохновился :) Начал искать нечто подобное для питона и не нашёл. Кстати, вы уже дописали replobj? Опубликовали исходники? Бегло глянул вашу статью про masterless консенсус — выглядит интересно. Это ваш собственный алогритм? Какая у него лицензия?
а отличаются ли операции чтения от операций записи? Все ли операции проходят через raft?
Через raft проходят только операции записи, чтение происходит напрямую. Все методы изменяющие состояние помечаются декоратором replicated.
Raft-кластер имеет одного лидера, в который идет вся запись. Верно ли я понимаю, что для распределения нагрузки предлагается создать несколько кластеров на разных портах?
Да, хороший вариант.
Расскажите, пожалуйста, как вы тестировали вашу реализацию Raft? Доступны ли где-то исходники этих тестов?
У нас есть несколько основных сценариев, среди которых падение и выбор лидера, log compaction, передача большого лога (50мб) и прочие. Исходники тестов здесь. Так же есть планы тестировать саму логику raft отдельно от сети и остальной обвязки, но для этого нужен небольшой рефакторинг.
zero-deployment нет, но идея интересная. Хотя я не очень представляю как именно это реализовать. Если на части машин будет одна версия класса, а на части машин — другая — во время применения журнала операций состояния классов разойдутся. Возможно у вас есть какие-то идеи?
Все ли данные, которые содержатся в экземпляре, должны быть сериализуемы pickle?
Именно так. Аргументы методов так же должны быть сериализуемы.
Верно ли, что изменения передаются в виде вызовов таких же методов на остальных нодах? Если какой-либо вызов какого-либо replicated метода инициализирует свойство экземпляра из внешнего объекта или из результата вызова системной функции, то содержимое на каждой ноде может получиться разным? К примеру, если метод записывает в свойство текущий timestamp.
Совершенно верно. В статье в примере distributed lock описана эта особенность. Timestamp-ы необходимо передавать в виде аргументов методам, точно так же как и сиды для рандома и прочее.
Динамическое добавление пока не поддерживается. Планирую добавить в следующей версии, благо сам протокол raft это позволяет. При разделении кластера — в случае если в одном из подкластеров больше половины нод — этот подкластер будет работать. Если во всех подкластерах меньше половины машин — коммиты транзакций происходить не будут (хотя они по прежнему будут добавлятся в лог старого лидера). Как только кластер восстановится — произойдет выбор нового лидера (предпочтение будет отдано ноде с логом наибольшей длины) и попытка закоммитить имеющиеся транзакции.
Что касается самой статьи — увы, она очень слабая, особенно с учетом того что на хабре уже есть много хороших статей по коллаборативной фильтрации, например эта или эта.
В machine-learning-е всё решает качество, решение превосходящее конкурентов буквально на несколько процентов (или даже долей) вполне может стоить 150 миллионов.
Подсказываю.
1) Не пишите статьи на темы в которых не разбираетесь. Ничего хорошего из этого не выйдет. Неужели это не было понятно после вашей предыдущей статьи?
2) Если хотите работу c++ сетевого разработчика — потрудитесь потратить время (несколько месяцев а не два дня) на то чтоб в деталях разобраться в сети на низком уровне, попробовать существующие фреймворки (boost asio / libevent / etc.); написать несколько простых сетевых приложений (чат, http сервер, etc.) и выложить их на гитхаб. После этого моментально работу найдёте.
Почему бы просто не запатчить redis с целью поддержки более длинных битовых полей?
Для redis есть http_api, например такое. Можно поставить его и написать процедуру на lua в которой будет вся логика.
HTTP намного более громоздкий чем родной redis-а, соотвественно часть времени будет тратится на парсинг и формирования запросов.
Ну и самое главное:
1) В redis есть журнал операций — соотвественно если инстанс редиса прибить он восстановит из журнала все последние записи. В вашем случае могут потерятся записи за последние 300 секунд.
2) В redis имеется репликация, если один инстанс ляжет — приложение может сходить в другой.
Ну а так вроде всё норм, только ещё бы batch запросы добавить.
В текущем виде они вполне себе успешно получат задания, но из за того что логика старых и новых воркеров разная — в лучшем случае старые воркеры покрешатся из за того что дернется к примеру не существующий метод — в худшем — разъедутся данные из за отличий в реализации таких-же методов.
Отчасти я вашей статьёй и вдохновился :) Начал искать нечто подобное для питона и не нашёл. Кстати, вы уже дописали replobj? Опубликовали исходники? Бегло глянул вашу статью про masterless консенсус — выглядит интересно. Это ваш собственный алогритм? Какая у него лицензия?
Через raft проходят только операции записи, чтение происходит напрямую. Все методы изменяющие состояние помечаются декоратором replicated.
Да, хороший вариант.
У нас есть несколько основных сценариев, среди которых падение и выбор лидера, log compaction, передача большого лога (50мб) и прочие. Исходники тестов здесь. Так же есть планы тестировать саму логику raft отдельно от сети и остальной обвязки, но для этого нужен небольшой рефакторинг.
Именно так. Аргументы методов так же должны быть сериализуемы.
Совершенно верно. В статье в примере distributed lock описана эта особенность. Timestamp-ы необходимо передавать в виде аргументов методам, точно так же как и сиды для рандома и прочее.
Что касается самой статьи — увы, она очень слабая, особенно с учетом того что на хабре уже есть много хороших статей по коллаборативной фильтрации, например эта или эта.
1) Не пишите статьи на темы в которых не разбираетесь. Ничего хорошего из этого не выйдет. Неужели это не было понятно после вашей предыдущей статьи?
2) Если хотите работу c++ сетевого разработчика — потрудитесь потратить время (несколько месяцев а не два дня) на то чтоб в деталях разобраться в сети на низком уровне, попробовать существующие фреймворки (boost asio / libevent / etc.); написать несколько простых сетевых приложений (чат, http сервер, etc.) и выложить их на гитхаб. После этого моментально работу найдёте.