Я просто разрабатываю систему анализа речи и ряда сопутствующих функционалов, и у меня ни в брокере сообщений, ни в базе данных, ничего не хранится не зашифрованным :) Я никого не заставляю так делать, но себе просто позволить не могу иначе🥲Разве что есть детерменированные алгоритмы шифрования, где мне нужен поиск, и не детерменированные, где нужна выше защищенность корпоративных данных. Я зделаю замеры и отпишусь! Завтра нужно поработать, потом я сделаю замеры, у меня просто есть убежденность что моя модель будет быстрей и более масштабируемой при росте записей в бд. Определить значения я не могу но пока уверен, что будет быстрее, не смотря на шифрование, тк рассчет до запроса к бд и очень дешевый. Но может бд как то оптимизирует хэши, и быстрей не будет, я проверю чтобы знать, отпишусь.
Ключ должен храниться не в базе, да он предполагается хотя бы в кэше, или в худшем случае хардкод в вашем сервисе, вплоть до персонального, с ним вычисляется сдвиг, преобразуясь в другое число в сервисе, и все ФИО тоже должны быть закодированны/зашифрованны. Поиск идет уже зашифрованым номером, со скоростью целочисленного сравнения, вместо построчного. При частом использовании должно быть быстрее, чем такая же операция посимвольно.. Таким образом сопоставить с данными людей не получится, хотябы, не зная полностью алгоритма и цифрового ключа. А так да, это не прям идеальное решение, но если скорость поиска и невозможность восстановления/сопоставления данных без знания 2х ключей в полной форме - невозможна. Есть интересные методы шифрования, которые маскируют энтропию информации в максимальную, с выравниванием по верхней границе можно, но на коротких данных, они менее заметный эффект оказывают, можно это делать по символу, или вычислять результат любой функцией, которая имеет обратную. Те репюнит был простейшим вариантом ключа, для понимания самой идеи хранить уже защищенное значение, это может быть просто какая то хэш функция малого размера, в обобщенном смысле, т.е. делать вычисление над номером, над фио, и при хранении и при поиске, при это целочисленная операция будетдешевле чем над строкой. Думаю на каком то масштабе запросов в секунды к БД мы сможем увидеть разницу. Интересно проверить, просто чтобы понимать есть ли ценность у такой идеи. Может разницы в скорости не будет, тогда конечно, можно строку как угодно шифровать. Я попробую попозже сделать эксперименты с заполнением базы и скорости поиска по мере ее наполненности, напишу сюда в коммент. Мне показалось это может быть удобной идеей и шифровать данные быстро и искать, потому я выбрал решение как выше масштабируемое. Я проверю, но напишу как время будет. Завтра понедельник, нужно поработать :) Я попробую сразу пару вариантов: хардкодный ключ в коде, персональный ключ в key-value кэше, и наполнять бд вплоть до всех возможных номеров пасспортов + разные функции, простое смещение, хэш функция, и другие симмитричные типо xor. Мне самому интересно и нужно, но для других значений, вроде дат рождений.
Здравствуйте! Спасибо за статью, было любопытно подумать. Хочу узнать что вы думаете о моем решении:
Первое что я подумал "Утечки персональных данных грозят большими штрафами" :) Потому я сразу размышлял что хранить в чистом виде номер будет ошибкой. Однако нужно давать возможность поиска, и сделать что-то в духе гомоморфных операций.
И тогда я решил, что нужно хранить данные в измененном виде. В качестве самой простой модификации добавиь repunit - число из единиц. Потому я выбрал целочисленный тип
Т.е. например серия 1234 номер 123456 превратились бы в 2345 23456. При этом зная алгоритм скрытия номера, можно было бы использовать repunit как модифицирующий ключ, для поиска в базе данных
Я не знал, что могут быть отедельно паспорта 0306 и 306, в целом никогда не видел в жизни номер начинающийся с 0, потому об этом не подумал. Но в моем решении это решается просто длиной repuinit, она должна быть тождественна длине серии+номеру. Т.е. для 306 и 0306 должно быть разное число единиц. Да возможно костыль, но если 0306 и 306 не возможны одновременно, даже он не требуется
Можно использовать 4 бита на кодирование последующего числа числа бит (все число вплоть до 15 бит при максимальном значении, но если оно например равно 1, отсечь все кроме первого бита)
Тогда сумарный минимум будет 5 бит, максимум 19: в среднем 12
Ещё немного можно отсечь комбинаций, из тех что следуют уже после победных, но я не использовал это
Партия состоит из 4х ходов максимум, после которого заканчивается победой крестиков или ноликов (1 бит)
Итого в лучшем случае 41 бит на партию (5 * 4 * 2 + 1), 153 бита максимум (19 * 4 * 2 + 1)
В среднем 97, против 120 на всю партию константно
Вероятно есть неточности, но я думаю что есть возможность хранить в среднем в меньшем пространстве чем 120 бит. И в чем я не уверен, но возможно можно задавать базисы, которые будут склонять запись партии к минимальному числу бит. Не уверен, что повороты точно помогут, но как одна из идей
Здесь смешены все возможные жанры, т.е. я не делал никакого разделения.
Я абсолютно с Вами согласен, я был бы очень рад получить отдельную статистику по разным жанрам, разным годам. К сожалению моя база не содержит названий исполнителей, если только они не указаны в самой табулатуре.
Я думаю о том, что возможно я соберу менее масштабную статистику, но по жанрам\исполнителям. Т.к. на трекерах можно найти базы данных табулатур по исполнителям, но они в несколько раз меньше чем данная база.
Согласен! Особенно это применимо к последней группе визуализаций)
Для меня эта работа просто нечто красивое и интересное. Я не профессиональный математик, скорее энтузиаст - но всегда с большим уважением и трепетом относился к математике. Может быть когда-нибудь из этого удастся сделать что-то более цельное :)
Спасибо большое за такой замечательный комментарий!
Каюсь, мой огрех - давно не доберусь до достойного изучения теории групп, хотя уже больше года на это нацелен. Надеюсь Ваш комментарий даст мне немного мотивационного топлива начать с этим работать!
Признаюсь честно, моя цель была привлечь внимание к тому, что псевдонаучная концепция эннеагрммы не более чем выдумка!
К моей большой радости одна из статей на википедии уже помечена псевдонаучной.
Но потом я вошёл во вкус - и мне просто понравилось визуализировать закономерности, которые я находил :)
Гипотетически предполагаю что какие-то из идей связанных с этой темой применимы в криптографии. Например можно создать метод быстрой вероятностной проверки является ли число циклическим и использовать огромные числа такой структуры как ключи.
Но это пальцем в небо, где это применить в точности - я не знаю.
Вторая причина почему я использовал именно числовые значения, это иметь последовательность значений, т.к. если бы значения были прописаны названиями нот, они бы были не упорядочены в интерактивных графиках. Схожая проблема была с размерами тактов.
Если Вам не сложно потратить 30 секунд своего времени, и сделать визуализацию - помогите мне пожалуйста. Я включу её в статью. Все csv файлы находятся в публичном доступе.
И да, Вы правы, я никогда в жизни не занимался визуализацией в Excel. Только matplotlib и отрисовка кодом вручную. Но я отказался от этих вариантов в пользу интерактивности.
По поводу следующей статьи, она должна раскрывать совсем другие закономерности. В частности описать ритмические структуры\паттерны, которые наиболее часто используют музыканты. И таким же образом мелодические последовательности.
Но я, конечно же, ни в коем случае не призываю Вас читать следующую статью. Я поступлю так, как проголосует большинство читателей.
Возможно это было вызвано тем, что часто не все ноты гаммы используются. Я использовал натуральные лады и пентатоники как трафарет, для определения тональности.
И часто бывали случаи когда это либо модуляция пентатоник (что возможно соответствовало бы какой-то гамме с пропущенной 1 нотой), либо модуляция диатоник.
Наиболее вероятно я буду писать вторую часть статьи, где приведу статистику ритмических и мелодических структур, понимание как это сделать есть ясное.
Ещё раз погружусь в этот вопрос и постараюсь достичь результата тем, или иным способом)
P.S. Если у Вас есть идеи о том, какую ещё информацию можно собрать, пожалуйста поделитесь ими. Если я достаточно быстро смогу написать алгоритм, я включу эти данные в следующую статью!
Я просто разрабатываю систему анализа речи и ряда сопутствующих функционалов, и у меня ни в брокере сообщений, ни в базе данных, ничего не хранится не зашифрованным :) Я никого не заставляю так делать, но себе просто позволить не могу иначе🥲Разве что есть детерменированные алгоритмы шифрования, где мне нужен поиск, и не детерменированные, где нужна выше защищенность корпоративных данных. Я зделаю замеры и отпишусь! Завтра нужно поработать, потом я сделаю замеры, у меня просто есть убежденность что моя модель будет быстрей и более масштабируемой при росте записей в бд. Определить значения я не могу но пока уверен, что будет быстрее, не смотря на шифрование, тк рассчет до запроса к бд и очень дешевый. Но может бд как то оптимизирует хэши, и быстрей не будет, я проверю чтобы знать, отпишусь.
Ключ должен храниться не в базе, да он предполагается хотя бы в кэше, или в худшем случае хардкод в вашем сервисе, вплоть до персонального, с ним вычисляется сдвиг, преобразуясь в другое число в сервисе, и все ФИО тоже должны быть закодированны/зашифрованны. Поиск идет уже зашифрованым номером, со скоростью целочисленного сравнения, вместо построчного. При частом использовании должно быть быстрее, чем такая же операция посимвольно.. Таким образом сопоставить с данными людей не получится, хотябы, не зная полностью алгоритма и цифрового ключа. А так да, это не прям идеальное решение, но если скорость поиска и невозможность восстановления/сопоставления данных без знания 2х ключей в полной форме - невозможна. Есть интересные методы шифрования, которые маскируют энтропию информации в максимальную, с выравниванием по верхней границе можно, но на коротких данных, они менее заметный эффект оказывают, можно это делать по символу, или вычислять результат любой функцией, которая имеет обратную. Те репюнит был простейшим вариантом ключа, для понимания самой идеи хранить уже защищенное значение, это может быть просто какая то хэш функция малого размера, в обобщенном смысле, т.е. делать вычисление над номером, над фио, и при хранении и при поиске, при это целочисленная операция будетдешевле чем над строкой. Думаю на каком то масштабе запросов в секунды к БД мы сможем увидеть разницу. Интересно проверить, просто чтобы понимать есть ли ценность у такой идеи. Может разницы в скорости не будет, тогда конечно, можно строку как угодно шифровать. Я попробую попозже сделать эксперименты с заполнением базы и скорости поиска по мере ее наполненности, напишу сюда в коммент. Мне показалось это может быть удобной идеей и шифровать данные быстро и искать, потому я выбрал решение как выше масштабируемое. Я проверю, но напишу как время будет. Завтра понедельник, нужно поработать :) Я попробую сразу пару вариантов: хардкодный ключ в коде, персональный ключ в key-value кэше, и наполнять бд вплоть до всех возможных номеров пасспортов + разные функции, простое смещение, хэш функция, и другие симмитричные типо xor. Мне самому интересно и нужно, но для других значений, вроде дат рождений.
Здравствуйте! Спасибо за статью, было любопытно подумать. Хочу узнать что вы думаете о моем решении:
Первое что я подумал "Утечки персональных данных грозят большими штрафами" :) Потому я сразу размышлял что хранить в чистом виде номер будет ошибкой. Однако нужно давать возможность поиска, и сделать что-то в духе гомоморфных операций.
И тогда я решил, что нужно хранить данные в измененном виде. В качестве самой простой модификации добавиь repunit - число из единиц. Потому я выбрал целочисленный тип
Т.е. например серия 1234 номер 123456 превратились бы в 2345 23456. При этом зная алгоритм скрытия номера, можно было бы использовать repunit как модифицирующий ключ, для поиска в базе данных
Я не знал, что могут быть отедельно паспорта 0306 и 306, в целом никогда не видел в жизни номер начинающийся с 0, потому об этом не подумал. Но в моем решении это решается просто длиной repuinit, она должна быть тождественна длине серии+номеру. Т.е. для 306 и 0306 должно быть разное число единиц. Да возможно костыль, но если 0306 и 306 не возможны одновременно, даже он не требуется
Спасибо большое автору, мне было интересно!
Можно использовать 4 бита на кодирование последующего числа числа бит (все число вплоть до 15 бит при максимальном значении, но если оно например равно 1, отсечь все кроме первого бита)
Тогда сумарный минимум будет 5 бит, максимум 19: в среднем 12
Ещё немного можно отсечь комбинаций, из тех что следуют уже после победных, но я не использовал это
Партия состоит из 4х ходов максимум, после которого заканчивается победой крестиков или ноликов (1 бит)
Итого в лучшем случае 41 бит на партию (5 * 4 * 2 + 1), 153 бита максимум (19 * 4 * 2 + 1)
В среднем 97, против 120 на всю партию константно
Вероятно есть неточности, но я думаю что есть возможность хранить в среднем в меньшем пространстве чем 120 бит. И в чем я не уверен, но возможно можно задавать базисы, которые будут склонять запись партии к минимальному числу бит. Не уверен, что повороты точно помогут, но как одна из идей
Извиняюсь, я кое-что не учел(отредактировал). Сейчас перепроверю свою идею
Большое вам спасибо! Я получил огромное удовольствие при прочтении статьи
Спасибо большое за такой тёплый отзыв!
Такие комментарии меня мотивируют продолжать писать статьи)
По данной теме у меня осталось ещё немного на следующую часть, но там есть одна закономерность которую я ещё не раскусил - как доделаю опубликую.
Будет тоже много визуализаций :)
Здесь смешены все возможные жанры, т.е. я не делал никакого разделения.
Я абсолютно с Вами согласен, я был бы очень рад получить отдельную статистику по разным жанрам, разным годам. К сожалению моя база не содержит названий исполнителей, если только они не указаны в самой табулатуре.
Я думаю о том, что возможно я соберу менее масштабную статистику, но по жанрам\исполнителям. Т.к. на трекерах можно найти базы данных табулатур по исполнителям, но они в несколько раз меньше чем данная база.
Что-то пошло не так c Stacked column cart)
Я в итоге использовал Stacked bars и оставил только топ, т.к. иначе выходило ещё объёмней чем прежде:
Исправил оба графика с нотами!
Ещё раз хочу поблагодарить за содействие :)
Спасибо большое за комментарий, он очень полезен!
К сожалению сейчас немного в стороне от возможности исправить графики, но постараюсь завтра до этого добраться! :)
Спасибо огромное за проделанную работу!
Ссылка к сожалению не открывается, потому что говорит что это не мой график, может быть там есть какие-то настройки приватности.
Как хорошо что есть такое замечательное место как Хабр, где можно делиться опытом и мнением :) Мне кажется это лучший ресурс всея интернета!
Круто! Я никогда не участвовал, но всегда воспринимал это как величественный проект!)
Согласен! Особенно это применимо к последней группе визуализаций)
Для меня эта работа просто нечто красивое и интересное. Я не профессиональный математик, скорее энтузиаст - но всегда с большим уважением и трепетом относился к математике. Может быть когда-нибудь из этого удастся сделать что-то более цельное :)
Спасибо большое за такой замечательный комментарий!
Каюсь, мой огрех - давно не доберусь до достойного изучения теории групп, хотя уже больше года на это нацелен. Надеюсь Ваш комментарий даст мне немного мотивационного топлива начать с этим работать!
Признаюсь честно, моя цель была привлечь внимание к тому, что псевдонаучная концепция эннеагрммы не более чем выдумка!
К моей большой радости одна из статей на википедии уже помечена псевдонаучной.
Но потом я вошёл во вкус - и мне просто понравилось визуализировать закономерности, которые я находил :)
Гипотетически предполагаю что какие-то из идей связанных с этой темой применимы в криптографии. Например можно создать метод быстрой вероятностной проверки является ли число циклическим и использовать огромные числа такой структуры как ключи.
Но это пальцем в небо, где это применить в точности - я не знаю.
Спасибо большое за тёплый отзыв! :)
Однако, интервалы в полутон популярней почти всех других, не считая интервала в 2 полутона)
Я если честно ожидал что они будут чуть более редкие)
Спасибо за обратную связь!
Я преследовал цель сделать интерактивные графики.
Вторая причина почему я использовал именно числовые значения, это иметь последовательность значений, т.к. если бы значения были прописаны названиями нот, они бы были не упорядочены в интерактивных графиках. Схожая проблема была с размерами тактов.
Если Вам не сложно потратить 30 секунд своего времени, и сделать визуализацию - помогите мне пожалуйста. Я включу её в статью. Все csv файлы находятся в публичном доступе.
И да, Вы правы, я никогда в жизни не занимался визуализацией в Excel. Только matplotlib и отрисовка кодом вручную. Но я отказался от этих вариантов в пользу интерактивности.
По поводу следующей статьи, она должна раскрывать совсем другие закономерности. В частности описать ритмические структуры\паттерны, которые наиболее часто используют музыканты. И таким же образом мелодические последовательности.
Но я, конечно же, ни в коем случае не призываю Вас читать следующую статью. Я поступлю так, как проголосует большинство читателей.
Отлично понимаю скептицизм!)
Возможно это было вызвано тем, что часто не все ноты гаммы используются. Я использовал натуральные лады и пентатоники как трафарет, для определения тональности.
И часто бывали случаи когда это либо модуляция пентатоник (что возможно соответствовало бы какой-то гамме с пропущенной 1 нотой), либо модуляция диатоник.
Наиболее вероятно я буду писать вторую часть статьи, где приведу статистику ритмических и мелодических структур, понимание как это сделать есть ясное.
Ещё раз погружусь в этот вопрос и постараюсь достичь результата тем, или иным способом)
P.S. Если у Вас есть идеи о том, какую ещё информацию можно собрать, пожалуйста поделитесь ими. Если я достаточно быстро смогу написать алгоритм, я включу эти данные в следующую статью!