>В даннй момент у нас примерно 2 ТБ данных в SQL (1.06/1.16 ТБ на первом кластере из 18 SSD и 0.889/1.45 ТБ на втором, состоящем из 4 SSD). Возможно, стоило бы задуматься об облаках, но сейчас мы используем SSD и время записи в базу равно буквально 0 миллисекундам
Возможно уже давно пора было задуматься о переносе базы с локальных винтов на внешнюю SAN хранилку, не?
Ну это шутка юмора, а вопрос все же висит: собственно говоря, во что на 10-ке у вас утыкалась производительность? Исключительно памяти не хватало? Просто довольно интересно, на таком не маленьком сете серверов где происходит затык.
Вообще ситуация выглядит странно: что-то не работает — а давайте обновимся до последней версии, не по красноглазому, что-ли.
Вообще мне нравиться raid5 в его реализации на 3par. Диски бьются на гиговые чанклетсы, собираются в группы + данные мажуться по всей группе чанклетсов мелкими блоками. Таким образом ребилд так нелюбимой вам пятерки проходит в считаные минуты.
Мне не нравятся оговорки «если важна скорость и надежность». Вы когда-нибудь встречали кастомера, которого волновали бы только скорость и надежность? Если да — 10-ку ему в плечи и не нужно ни 5-ки ни 6-ки ни прочих извратов. Всегда есть вопрос, что же важнее. И пока все конторы в которых я проводил инсталяции выбирали небольшой прирост производительности в угоду не очевидному выигрышу в надежности.
Как мне нравятся такие советчики. Почему? Что за бред с 50-м рейдом. Ладно, допустим, вы являетесь фанатом NetAPP и будите доказывать с пеной у рта, что 5-й рейд небезопасен и его нельзя использовать в продуктиве. Не хочу влазить в холивар. Но 50-й то рейд в таком случае зачем? и нафига 60-й?
P.S. мне действительно интересно, кто это использует.
Сложилось впечатление, что кто-то нашел методичку и сделал выдержку оттуда, изредка заменяя предложения, чтобы вроде как не просто скопипастить.
У нас так обычно лабы сдавались на младших курсах.
В плане сложности алгоритма — если использовать алгоритм с шифрованием голоса каждого участника то получаем N вычислений
Если использовать конкатенацию + hash на этапе вычисления результатов — это те же самые N вычислений хэша, но при этом мы не решаем проблему, если последним голосует заговорщик — ему всего-лишь нужно будет в онлайне просчитывать хэши а не суммы или xor-ы
Ну если абстрагироваться от конкретной ситуации — если известен алгоритм расчета значений — просчитать результат не проблема. Если алгоритм неизвестен, то рано или поздно он станет известен :)
Несколько раундов опять же решают проблему только частично — при сговоре вероятность выбора неугодного человека все-равно в несколько раз больше честного голосования(прямо пропорционально количеству заговорщиков), т.к достаточно только выпасть паре — сговорщик с шифрованным сообщением+сговорщик голосующий последним и результат определен.
В варианте, который я предложил, даже если 3 из 4 человек участвуют в сговоре, они не могут предугадать, что конкретно загадает жертва + секрет не зависит от вариантов алгоритма подсчета.
Этот алгоритм конечно не защищен с точки зрения отрицания(можно конечно добавить неотрицаемые подписи), но для данной задачи это не принципиально.
По дороге домой размышлял, каким бы образом я пытался мухлевать в данной ситуации и таки придумал, что можно сделать.
Если Алиса состоит в сговоре с кем-то, то она может либо вбить число состоящее из одних только нулей и таким образом отказаться от своего голоса, либо сообщить последнему голосующему свое число(по сути то же самое, но на одну операцию вычисления больше).
В чистом остатке — Алиса + последний голосующий решают кого отправить в поход. Стойкость алгоритма должна гарантироваться невозможностью менять результат в процессе объявления.
Да, посыпаю голову пеплом, в вашем алгоритме хеш считается только один раз, хотя меня и смущает доверие одному человеку функции держателя секрета (то-есть когда от его данных зависит результат).
А по сути своей не важно как будет выбираться ЗНАЧАЩЕЕ число(то которое будет складываться в общую сумму). Ведь мы же не будем знать такие числа для других участников голосования. Его достоверность мы в конце просто проверим сложив с солью и применив к ним ключ — на выходе должны получить заявленный в начале hash.
Ну а сумма рандомных чисел от каждого участника — есть величина случайная(если не брать во внимание возможность любимых чисел и прочих индивидуальных особенностей).
UPD — для решения исходной задачи — делаем то же самое, но пишем вместо имени избранника рандомное число. В конце считаем что-то наподобие div 4 от суммы всех чисел и отправляем участника под сим гордым номером за пивом.
Ах боже мой, прошу прощения — в пылу сражений я неверно осознал для себя задачу и предложил решение для честного открытого голосования. для отправки гонца.
По сей причине приношу свои извинения.
По сути своей я просто предложил публичную проверку по примеру авторизации в Unix.
Вобщем-то показанный алгоритм не соответствует решаемой задаче. (Насколько я понимаю это алгоритм Честных выборов Меррита). В той же прикладной криптографии есть алгоритм честного бросания монетки, и в данном конкретном случае, вполне себе достаточно обобщить его на количество участников > 2.
Например так:
Каждый участник голосования пишет имя, добавляет к нему рандомную строку. Шифрует произвольным ключом.
Показывает всем хеш и рандомную строку.
После того, как все показали свою значения hash + Random — можно публично оглашать результаты + в подтверждение показывать свой ключ для проверки.
В данном конкретном случае такой алгоритм позволит уберечься от каких-то лишних телодвижений.
Прошу прощения, если я настолько косноязычен, что не смог донести свою мысль касательно п.3. «Вы измеряете не то и не там.»
Лично мое мнение — технарь должен считать свои метрики, исходя из которых он может плясать — например загрузка цпу, время выполнения дисковых операций, да пусть это даже будет энергопотребление в датацентре. Но это никак не время доступности системы, TCO и прочие вещи, необходимые для бизнеса. В моем понимании эти метрики позволяют оценить работу этого технаря и поэтому у него не должно быть возможности ими манипулировать + собственно говоря это задача его менеджера — предоставлять подобную статистику не вникая в технические детали.
Прошу прощения, но первая мысль, которая возникает при прочтении названия — «Да пошел бы ты №$%^ !»
После прочтения всего перевода — едкое чувство недовольства и несогласия. Итак:
п.1 — Лично я считаю, что инструменты должны быть удобными, и если мне удобно юзать какти в одном месте, а nagios в другом, я вероятнее всего так и сделаю и мне будет начхать, на то, что это не вписывается в чью-то общую картину мира.
п.2 — Я вообще не понял, если кто-то не в состоянии описать проблему в email, то навряд ли он сделает это лучше в баг/таск трекере.
п.3 — После «бездействие в подстраивании технологии под нужды бизнеса» дальше вообще не читал. Тут вообще, по сути своей ошибка — какого черта технари должны считать метрики бизнеса? Особенно если учитывать, что на этих метриках считается продуктивность этих же технарей.
В общем сама по себе тема интересна, но вот мысли автора меня несколько смущают.
P.S. Переводчику огромное спасибо, прочиталось довольно легко. Жду следующие главы, чтобы можно было дальше злиться и не соглашаться.
Возможно уже давно пора было задуматься о переносе базы с локальных винтов на внешнюю SAN хранилку, не?
Ну это шутка юмора, а вопрос все же висит: собственно говоря, во что на 10-ке у вас утыкалась производительность? Исключительно памяти не хватало? Просто довольно интересно, на таком не маленьком сете серверов где происходит затык.
Вообще ситуация выглядит странно: что-то не работает — а давайте обновимся до последней версии, не по красноглазому, что-ли.
Вы так говорите, будто это серьезный показатель хорошей работы.
+ необходимость своего шейпера без BQL, как бы намекает на отсутствие нормальной борьбы с TCP синхронизацией?
Мне не нравятся оговорки «если важна скорость и надежность». Вы когда-нибудь встречали кастомера, которого волновали бы только скорость и надежность? Если да — 10-ку ему в плечи и не нужно ни 5-ки ни 6-ки ни прочих извратов. Всегда есть вопрос, что же важнее. И пока все конторы в которых я проводил инсталяции выбирали небольшой прирост производительности в угоду не очевидному выигрышу в надежности.
P.S. мне действительно интересно, кто это использует.
У нас так обычно лабы сдавались на младших курсах.
P.S. Спасибо за интересные замечания.
Если использовать конкатенацию + hash на этапе вычисления результатов — это те же самые N вычислений хэша, но при этом мы не решаем проблему, если последним голосует заговорщик — ему всего-лишь нужно будет в онлайне просчитывать хэши а не суммы или xor-ы
Несколько раундов опять же решают проблему только частично — при сговоре вероятность выбора неугодного человека все-равно в несколько раз больше честного голосования(прямо пропорционально количеству заговорщиков), т.к достаточно только выпасть паре — сговорщик с шифрованным сообщением+сговорщик голосующий последним и результат определен.
В варианте, который я предложил, даже если 3 из 4 человек участвуют в сговоре, они не могут предугадать, что конкретно загадает жертва + секрет не зависит от вариантов алгоритма подсчета.
Этот алгоритм конечно не защищен с точки зрения отрицания(можно конечно добавить неотрицаемые подписи), но для данной задачи это не принципиально.
Если Алиса состоит в сговоре с кем-то, то она может либо вбить число состоящее из одних только нулей и таким образом отказаться от своего голоса, либо сообщить последнему голосующему свое число(по сути то же самое, но на одну операцию вычисления больше).
В чистом остатке — Алиса + последний голосующий решают кого отправить в поход. Стойкость алгоритма должна гарантироваться невозможностью менять результат в процессе объявления.
Ну а сумма рандомных чисел от каждого участника — есть величина случайная(если не брать во внимание возможность любимых чисел и прочих индивидуальных особенностей).
По сей причине приношу свои извинения.
По сути своей я просто предложил публичную проверку по примеру авторизации в Unix.
Например так:
Каждый участник голосования пишет имя, добавляет к нему рандомную строку. Шифрует произвольным ключом.
Показывает всем хеш и рандомную строку.
После того, как все показали свою значения hash + Random — можно публично оглашать результаты + в подтверждение показывать свой ключ для проверки.
В данном конкретном случае такой алгоритм позволит уберечься от каких-то лишних телодвижений.
Лично мое мнение — технарь должен считать свои метрики, исходя из которых он может плясать — например загрузка цпу, время выполнения дисковых операций, да пусть это даже будет энергопотребление в датацентре. Но это никак не время доступности системы, TCO и прочие вещи, необходимые для бизнеса. В моем понимании эти метрики позволяют оценить работу этого технаря и поэтому у него не должно быть возможности ими манипулировать + собственно говоря это задача его менеджера — предоставлять подобную статистику не вникая в технические детали.
После прочтения всего перевода — едкое чувство недовольства и несогласия. Итак:
п.1 — Лично я считаю, что инструменты должны быть удобными, и если мне удобно юзать какти в одном месте, а nagios в другом, я вероятнее всего так и сделаю и мне будет начхать, на то, что это не вписывается в чью-то общую картину мира.
п.2 — Я вообще не понял, если кто-то не в состоянии описать проблему в email, то навряд ли он сделает это лучше в баг/таск трекере.
п.3 — После «бездействие в подстраивании технологии под нужды бизнеса» дальше вообще не читал. Тут вообще, по сути своей ошибка — какого черта технари должны считать метрики бизнеса? Особенно если учитывать, что на этих метриках считается продуктивность этих же технарей.
В общем сама по себе тема интересна, но вот мысли автора меня несколько смущают.
P.S. Переводчику огромное спасибо, прочиталось довольно легко. Жду следующие главы, чтобы можно было дальше злиться и не соглашаться.