Я к сожалению заболел, потому полная выкладка задерживается, но основные выводы такие:
1. Зашифровать bigint и расшифровать намного быстрее, чем строчку. Если хранить данные защищенными сразу, bigint выигрывает
2. Искать по bigint в равных условиях всегда быстрее
3. Если применять индексы, скорость поиска возрастает, НО за счет замедления вставки и обновления
4. Большинство эффектов возникают на размерах таблиц выше 10 в 6+ степени
Я постараюсь сделать потом небольшую статью (если цифры будут интересными), для того чтобы провести замеры и провести анализ. Если цифры буду посредственные - отпишусь тут
Но из того что я вижу, bigint при условии хранения в защищенном или хэшированном значении будет быстрее:
1. Сама операция шифрования значения (перед поиском, вставкой, изменением)
2. Поиск в базе данных по bigint будет быстрее
3. Сама вставка будет быстрее (особенно за счет индексов для посимвольных данных)
Итого если акцент на зашифрованности и скорости - такой вариант во всех смыслах лучше.
Самый главный вопрос - сколько записей должно храниться в БД. А так я почитал, серии из 3х чисел не бывает, потому все в порядке с изначальной логикой, костыли не нужны. Я постараюсь все довести до какой-то интересной формы сравнения. Где можно будет сравнить быстродеятельность и защищенность решения.
Мой акцент такой: я считаю что мое решение будет более быстрое, даже если сравнивать с незащищенным решением по символам, при этом в качестве бонуса - защищенность.
А теперь самое важное - такую базу данных придется по хорошему сегментировать, если предполагать что мы хотим хранить все возможные номера паспортов, и тут тоже нужно рассмотреть стратегии сегментирования. Т.к. если мы например строим сервис, который обрабатывает очень много данных, и содержит записи о всех существующих паспортах, нам может оказаться крайне невыгодно использовать другие типы данных.
Я считаю, что абсолютно защищенных программ не бывает, и полностью быть уверенным что однажды доступ к БД не будет получень злоумышленником, тяжело.
Сказывается что я храню буквально самые ценные коммерческие данные, раскрытие которых ставит под угрозу коммерческую тайну фирм. Причем бывают разные случаи, вроде старых бэкапов БД о которых забыли и они остались где-то в незащищенном виде. По поводу индексации - в предложенном мной варианте она должна удачно работать.
Я к сожалению заболел, и по вечерам быстро не напишу набор сравнений, но пока что схожу выглядит что мой вариант самый выгодный если есть цель 1. Обеспечить максимальную скорость поиска и вставки (индекс на символы ускорит поиск, замедлив вставку, на скольких миллионах записей это станет заметным) 2. Хранить данные зашифрованными так, чтобы их можно было сравнивать без расшифровки. Я постараюсь потом провести замеры. Если ничего интересного не будет - отпишусь просто тут, если будет интересно - выложу как статью
Я просто разрабатываю систему анализа речи и ряда сопутствующих функционалов, и у меня ни в брокере сообщений, ни в базе данных, ничего не хранится не зашифрованным :) Я никого не заставляю так делать, но себе просто позволить не могу иначе🥲Разве что есть детерменированные алгоритмы шифрования, где мне нужен поиск, и не детерменированные, где нужна выше защищенность корпоративных данных. Я зделаю замеры и отпишусь! Завтра нужно поработать, потом я сделаю замеры, у меня просто есть убежденность что моя модель будет быстрей и более масштабируемой при росте записей в бд. Определить значения я не могу но пока уверен, что будет быстрее, не смотря на шифрование, тк рассчет до запроса к бд и очень дешевый. Но может бд как то оптимизирует хэши, и быстрей не будет, я проверю чтобы знать, отпишусь.
Ключ должен храниться не в базе, да он предполагается хотя бы в кэше, или в худшем случае хардкод в вашем сервисе, вплоть до персонального, с ним вычисляется сдвиг, преобразуясь в другое число в сервисе, и все ФИО тоже должны быть закодированны/зашифрованны. Поиск идет уже зашифрованым номером, со скоростью целочисленного сравнения, вместо построчного. При частом использовании должно быть быстрее, чем такая же операция посимвольно.. Таким образом сопоставить с данными людей не получится, хотябы, не зная полностью алгоритма и цифрового ключа. А так да, это не прям идеальное решение, но если скорость поиска и невозможность восстановления/сопоставления данных без знания 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 бит. И в чем я не уверен, но возможно можно задавать базисы, которые будут склонять запись партии к минимальному числу бит. Не уверен, что повороты точно помогут, но как одна из идей
Здесь смешены все возможные жанры, т.е. я не делал никакого разделения.
Я абсолютно с Вами согласен, я был бы очень рад получить отдельную статистику по разным жанрам, разным годам. К сожалению моя база не содержит названий исполнителей, если только они не указаны в самой табулатуре.
Я думаю о том, что возможно я соберу менее масштабную статистику, но по жанрам\исполнителям. Т.к. на трекерах можно найти базы данных табулатур по исполнителям, но они в несколько раз меньше чем данная база.
Согласен! Особенно это применимо к последней группе визуализаций)
Для меня эта работа просто нечто красивое и интересное. Я не профессиональный математик, скорее энтузиаст - но всегда с большим уважением и трепетом относился к математике. Может быть когда-нибудь из этого удастся сделать что-то более цельное :)
Спасибо большое за такой замечательный комментарий!
Каюсь, мой огрех - давно не доберусь до достойного изучения теории групп, хотя уже больше года на это нацелен. Надеюсь Ваш комментарий даст мне немного мотивационного топлива начать с этим работать!
Признаюсь честно, моя цель была привлечь внимание к тому, что псевдонаучная концепция эннеагрммы не более чем выдумка!
К моей большой радости одна из статей на википедии уже помечена псевдонаучной.
Но потом я вошёл во вкус - и мне просто понравилось визуализировать закономерности, которые я находил :)
Гипотетически предполагаю что какие-то из идей связанных с этой темой применимы в криптографии. Например можно создать метод быстрой вероятностной проверки является ли число циклическим и использовать огромные числа такой структуры как ключи.
Но это пальцем в небо, где это применить в точности - я не знаю.
Я к сожалению заболел, потому полная выкладка задерживается, но основные выводы такие:
1. Зашифровать bigint и расшифровать намного быстрее, чем строчку. Если хранить данные защищенными сразу, bigint выигрывает
2. Искать по bigint в равных условиях всегда быстрее
3. Если применять индексы, скорость поиска возрастает, НО за счет замедления вставки и обновления
4. Большинство эффектов возникают на размерах таблиц выше 10 в 6+ степени
Я постараюсь сделать потом небольшую статью (если цифры будут интересными), для того чтобы провести замеры и провести анализ. Если цифры буду посредственные - отпишусь тут
Но из того что я вижу, bigint при условии хранения в защищенном или хэшированном значении будет быстрее:
1. Сама операция шифрования значения (перед поиском, вставкой, изменением)
2. Поиск в базе данных по bigint будет быстрее
3. Сама вставка будет быстрее (особенно за счет индексов для посимвольных данных)
Итого если акцент на зашифрованности и скорости - такой вариант во всех смыслах лучше.
Самый главный вопрос - сколько записей должно храниться в БД.
А так я почитал, серии из 3х чисел не бывает, потому все в порядке с изначальной логикой, костыли не нужны. Я постараюсь все довести до какой-то интересной формы сравнения. Где можно будет сравнить быстродеятельность и защищенность решения.
Мой акцент такой: я считаю что мое решение будет более быстрое, даже если сравнивать с незащищенным решением по символам, при этом в качестве бонуса - защищенность.
А теперь самое важное - такую базу данных придется по хорошему сегментировать, если предполагать что мы хотим хранить все возможные номера паспортов, и тут тоже нужно рассмотреть стратегии сегментирования. Т.к. если мы например строим сервис, который обрабатывает очень много данных, и содержит записи о всех существующих паспортах, нам может оказаться крайне невыгодно использовать другие типы данных.
Я считаю, что абсолютно защищенных программ не бывает, и полностью быть уверенным что однажды доступ к БД не будет получень злоумышленником, тяжело.
Сказывается что я храню буквально самые ценные коммерческие данные, раскрытие которых ставит под угрозу коммерческую тайну фирм. Причем бывают разные случаи, вроде старых бэкапов БД о которых забыли и они остались где-то в незащищенном виде. По поводу индексации - в предложенном мной варианте она должна удачно работать.
Я к сожалению заболел, и по вечерам быстро не напишу набор сравнений, но пока что схожу выглядит что мой вариант самый выгодный если есть цель 1. Обеспечить максимальную скорость поиска и вставки (индекс на символы ускорит поиск, замедлив вставку, на скольких миллионах записей это станет заметным) 2. Хранить данные зашифрованными так, чтобы их можно было сравнивать без расшифровки. Я постараюсь потом провести замеры. Если ничего интересного не будет - отпишусь просто тут, если будет интересно - выложу как статью
Я просто разрабатываю систему анализа речи и ряда сопутствующих функционалов, и у меня ни в брокере сообщений, ни в базе данных, ничего не хранится не зашифрованным :) Я никого не заставляю так делать, но себе просто позволить не могу иначе🥲Разве что есть детерменированные алгоритмы шифрования, где мне нужен поиск, и не детерменированные, где нужна выше защищенность корпоративных данных. Я зделаю замеры и отпишусь! Завтра нужно поработать, потом я сделаю замеры, у меня просто есть убежденность что моя модель будет быстрей и более масштабируемой при росте записей в бд. Определить значения я не могу но пока уверен, что будет быстрее, не смотря на шифрование, тк рассчет до запроса к бд и очень дешевый. Но может бд как то оптимизирует хэши, и быстрей не будет, я проверю чтобы знать, отпишусь.
Ключ должен храниться не в базе, да он предполагается хотя бы в кэше, или в худшем случае хардкод в вашем сервисе, вплоть до персонального, с ним вычисляется сдвиг, преобразуясь в другое число в сервисе, и все ФИО тоже должны быть закодированны/зашифрованны. Поиск идет уже зашифрованым номером, со скоростью целочисленного сравнения, вместо построчного. При частом использовании должно быть быстрее, чем такая же операция посимвольно.. Таким образом сопоставить с данными людей не получится, хотябы, не зная полностью алгоритма и цифрового ключа. А так да, это не прям идеальное решение, но если скорость поиска и невозможность восстановления/сопоставления данных без знания 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 полутона)
Я если честно ожидал что они будут чуть более редкие)