UUID и браузеры. Почему фронтенд живет без страшных айдишников?

    Решил я делать свой пет-проект по учету прочитанных книг на PWA. Покорять новые технологии и все такое. Расчет был на то, что с его выложу и установлю на телефон и вот у меня есть мобильное приложение, которое можно использовать оффлайн. Хочу я сгенерировать UUID, чтобы сохранить книгу, а не нахожу API. Предлагаю разобраться почему.


    Что такое UUID


    UUID — стандарт идентификации данных используемый, преимущественно, для распределенных систем. Его задача позволить генерировать ключи, которые не вызовут конфликтов при сохранении в то, или иное хранилище данных.


    UUID представляет собой 16-байтное число в HEX'е формате:


    xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx


    Где:


    x - [0 - f] (Закодированные данные)
    M - [0 - 5] (Версия UUID)
    N - [8 - b] (Вариант UUID)

    Здесь я не буду вдаваться в подробности, что из этого что означает. С этим вы подробно можете ознакомиться в википедии.


    Способы генерации UUID



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


    1 и 2 версии использовали время с точностью до 0.1 микросекунды + MAC адрес, что гарантировало практически полное отсутствие возможности получить дубликат. Чтобы полностью добить эту вероятность первая версия добавляет рандомную соль, а вторая ничего не делает (вторую версию мы не любим, она вообще может сгенерировать только 64 уникальных id за семь минут).


    3 и 5 хешируют пространство имен (Url, FQDN, OID) + само имя. Таким образом в каждый момент времени мы получаем абсолютно идентичные UUID для одних и тех же входных параметров.


    Отличие 3 и 5 версии только в том, что 3 использует для хеширования MD-5, а 5 — SHA-1.

    4 же версия просто использует рандом ¯_(ツ)_/¯.


    Почему его нет в браузере


    JS не имеет доступа к данным машины


    Мы не можем получить MAC-адрес пользователя, мы не можем получить данные его IP, а так же вообще что-либо с его машины без разрешения пользователя.
    Да, мы можем загружать файлы и делать красивые file-инпуты на фронте, но мы можем получить только конкретный файл, который нам предоставит пользователь. Но согласитесь, как бы не шибко удобно запрашивать на каждый UUID по файлу. Неудобно их запрашивать даже каждый раз при входе на сайт.
    Сделано же это из благих целей: представьте, что читаете вы Хабр, а тут:



    import * as console from 'console';
    
    console.run('rm -rf /**/kursach*final-(\d+)?.docx')

    И больше никаких проблем с высшим образованием.


    Потому что до недавних пор он был просто не нужен


    Браузер для того, чтобы сидеть в интернете.
    Через браузер мы заходим на сайт. Если мы зашли на сайт — нам отдали страничку. А раз нам ее отдали — значит мы связаны с сетевым узлом который может сгенерировать UUID и сами мы можем этого не делать. По факту, нам как фронту вообще на ID информации все равно, мы отдали, а дальше это уже проблема принимающей стороны.


    Вы можете возразить, что есть PWA, и что оно есть аж с 2007 года. Но так уж вышло, что PWA никому не нужен, примерно, с того же самого времени. (Хотя нынче Play Market позволяет загружать PWA как приложения, но...). Сами посудите, много вы PWA приложений установили? Я даже Хабр не поставил.


    Другой вопрос — почему до сих тор нет никакого API типа getUUID(), чтобы переложить эту проблему на браузер? Скорее всего ответ кроется все в той же ссылке на то, что в 99 случаев из 100 сайту это просто-напросто незачем.


    Но осадочек остался.


    Какие трудности вас ждут


    Точность времени


    Я бы не стал называть это большой проблемой.


    Мы можем получить время с точностью только до миллисекунды, в то время как первая версия UUID делала это с точностью до 100 наносекунд.


    Ну чисто теоретически мы можем получить и с точностью до 1 микросекунды, но это будет время от открытия вкладки (это если мы сейчас про performance.now()), что уже не так заманчиво.


    Идентификация браузера


    Браузеры вообще не уникальны и сейчас я вам это докажу.


    Для идентификации клиента HTML Living Standard нам предлагает использовать The Navigator object.


    А теперь внимание сравним то, что нам предлагают сравнивать


    Браузер appCodeName appName platform ​product productSub vendor vendorSub
    Chrome Mozilla Netscape Win32 Gecko 20030107 Google Inc. -
    Mozilla 75 Mozilla Netscape Win32 Gecko 20100101 - -
    Mozilla 45 Mozilla Netscape Win32 Gecko 20100101 - -
    Internet Explorer Mozilla Netscape Win32 Gecko - - -
    Microsoft Edge Mozilla Netscape Win32 Gecko 20030107 Google Inc. -

    Как вам такое? Почувствовали все разнообразие клиентов? Вот и я нет.


    Но надо признать, что местами отличаются userAgent и appVersion:


    Браузер appVersion userAgent
    Chrome 5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36
    Mozilla 75 5.0 (Windows) Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0
    Mozilla 45 5.0 (Windows) Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
    Internet Explorer 5.0 (Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; Tablet PC 2.0; Zoom 3.6.0; rv:11.0) like Gecko Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; Tablet PC 2.0; Zoom 3.6.0; rv:11.0) like Gecko
    Microsoft Edge 5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36 Edg/88.0.705.74 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36 Edg/88.0.705.74

    Тут Edge впереди планеты всей, так как он отображает IP, и мы можем использовать его. Но это только в Edge. А так, как видите, многого с навигатором не навоюешь.


    Как это реализовал я



    Для себя я решил отталкиваться от своих нужд и особенностей архитектуры своего приложения.


    1. Книги очень сложно добавлять несколько раз в миллисекунду. Даже просто тыкать на кнопочку сложно.
    2. Книги может добавлять только авторизованный пользователь.

    Я первые 6 байт из 16 отвел под миллисекунды timestamp'а, что дает нам возможность генерировать ключи аж до 10889-08-02Т10:31:50.655. Хватит с запасом.


    Последние 6 байт я беру из SHA-1 хеша логина — можно идентифицировать 281,474,976,710,656 уникальных пользователей (если взять расчет на то, что не будет коллизий). Тоже с запасом (у меня их всего 30).


    1 байт у нас отводится на версию (M) и вариант (N).


    Оставшиеся 3 байта я солю рандомом.


    Что в итоге:


    Если вдруг мое приложение станет супер-пупер популярным и 100,000 и они будут за минуту каждый делать по 100 книг, то за миллисекунду будет генерироваться:


    $$
    100,000 * 100 / 60,000 = 166
    $$


    Вероятность того, что совпадут два:


    $$
    166 1/256^3 1/256^5 = 166 1/255^8 = 166 / 18 10^{18}
    $$


    Это очень мало и этого мне хватает


    Реализацию можно посмотреть тут.


    Предвещая вопрос "А почему же не рандом?"


    Да, есть такой легендарный код


    function uuidv4() {
        return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {
            var r = Math.random() * 16 | 0, v = c == 'x' ? r : (r & 0x3 | 0x8);
            return v.toString(16);
        });
    }

    В моем случае на бэкенде UUID используется как первичный ключ.


    Когда первые байты ключа идут по порядку больше вероятность, что новая запись встанет в конец таблицы. Даже если на клиенте будет запущена синхронизация. Ведь вряд ли юзер выполнит синхронизацию данных внесенных полгода назад и СУБД будет сдвигать половину таблицы.


    В случае же с рандомом — данные будут вставляться в табличку куда ни попадя.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 246

      +5
      новая запись встанет в конец таблицы.
      СУБД будет сдвигать половину таблицы.

      Это какие базы данных по-умолчанию таблицы двигают чтобы одну строчку вставить?


      В случае же с рандомом — данные будут вставляться в табличку куда ни попадя.

      Сильное заявление. Как минимум, это очень зависит от базы данных. А ещё зависит от характера работы с данными.


      postgres, например, будет вставлять всегда, так скажем, в конец таблицы, если нет свободного места (после вакуума). А его не будет, если в таблицу вы только добавляете записи.


      mysql, кажется, всегда вставляет в конец, но здесь могу ошибаться, да и движки там разные.


      Некоторые time-series БД действительно делают примерно то, что вы говорите, но они это делают не в момент вставки, а после накопления изменений в фоне. Но применить этот кейс в целом ко всем СУБД выглядит сомнительным.

        +3

        В случае кластерного индекса в SQL Server вставка со случайными идентификаторами действительно хуже, чем когда они монотонно возрастают, из-за более сильной фрагментации индекса и меньшего процента заполнения страниц. Помимо этого для любой СУБД такой сценарий менее эффективен с точки зрения использования кеша страниц — случайные чтения и записи потребуют много страниц держать в памяти и/или часто подгружать с диска. Так что здравое зерно есть. Другое дело, что эффект будет заметен только на довольно больших данных/нагрузках. Для среднего размера приложения его и под лупой не разглядеть, мне кажется.

          0
          Пришел ответить на ваш комментарий, но за меня это сделал pankraty.
          От себя могу добавить, что использую я postgres, книги ± всегда будут вставляться в конец таблицы из-за возрастающего ПК. Но и вакуум у меня будет, т.к. сервисом предусмотрено и удаление книг.
            +1
            вместо удаления добавьте колонку deleted_at с типом таймстамп. решит кучу проблем. и вакуум не надо делать и востановить случайно удаленные данные можно
              0
              Разве update не делает новую версию записи, размещая её в новой странице?
          –1
          Использование обычного UUID в качестве первичного ключа в MySQL это сразу удар по скорости вставки (вставка в случайное место вместо дописывания в конец в случае обычного автоинкремента) и JOIN-aм, т.к. первичный ключ является кластерным, а искать по строкам — такая себе идея.
            0

            Так вроде ж BINARY(16), нет?

              –1
              Не особо важно, т.к. всё равно лучше использовать автоинкремент как первичный ключ: будут максимально быстрые вставки и JOIN-ы, а на UUID сделать уникальный индекс и использовать его как идентификатор сущностей для внешних клиентов сервиса.
              0

              В какое такое случайное место?

                0
                В случайное место на диске, где хранится индекс.
                  0
                  Индекс не флашится на диск разу при записи.
                  О чем идет речь?
                0
                Не подскажите, пожалуйста, где можно про это прочитать? Всегда думал, что нет большой разницы автоинкремент или uuid в качестве первичного. От типа первичного ключа не зависит куда пишутся данные — в конец или в середину файла. Это решают другие алгоритмы. При вставке просто обновляется первичный индекс, что не более затратно, чем обновлять такой же уникальный.
                  –1

                  Почитайте про первичные ключи. Как правило ПК всегда отсортирован.
                  И когда вы вставляете рандомный UUID он может расположиться в середине или, не дай бог, начале кластерного индекса и тогда пошло-поехало.
                  В данном случае считается дорогим обновление индекса.
                  Но в случае с моей реализацией UUID так же как и с UUIDv1, и с UUIDv2 этого происходить не будет, т.к. они последовательны, а не случайны.
                  Каждый последующий добавленный "старше" предшественника.

                    +1
                    Если UUID генерируются разными приложениями — наивно полагать, что у них идеально синхронизованы часы. Про разные MAC адреса — тем более. Так что никаких строгих гарантий последовательности создаваемых значений, если они генерируются разными приложениями нет.

                    Вы же предлагаете использовать ещё и хэширование (считай, рандом), да ещё и создавать это с кучи браузерных клиентов — откуда вообще основания полагать, что значения будут последовательны? Скорее они будут не так сильно размазаны, как UUIDv4, но давать какие-то оценки того, что «кластерность» вставок будет достаточная, чтобы не создавать проблемы — я бы не стал.
                      +1

                      А зачем приложения генерят ПК? Пусть это делает тот, кто должен это делать — БД.

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

                          У вас есть простое и неправильное решение. Это наоборот усложнение задачи.
                            0
                            В случае шардирования я выбираю ключ шарда и генерирую айди на клиенте — это существенно проще, чем ждать бд.

                            А что уж вы там себе сами придумали — мне неизвестно.
                              0
                              Я могу только повториться «Если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию.»

                              Нельзя делать такой хрупкий софт. Тем более большой софт. Раз у вас шардирование есть значит софт большой.
                              Софт должен переживать сильные возмущения во внешней среде. А у вас все развалится с первого удара.
                                +1
                                Красивые домыслы. Без аргументов и фактов.

                                Бывает.
                                  0
                                  Вы же не услышите все равно. Но давайте попробуем.

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

                                  Менять схему шардирования на живую очень сложно и очень опастно. Потерять даннные при перешардировании как нефиг делать. Завалить все приложение еще проще. А уж про потери времени разработчиков и потенциально бессонные ночи я даже вспоминать не буду.
                                  Это тоже причины делать шардирование наиболее надежным способом.

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

                                  Это точно недостаточно хороший результат для выбора такой схемы шардирования. Софт надо перепроектировать. А для начала надо обвесить костылями, мониторингами и автобанилками плохих клиентов это место. Чтобы максимально понизить вероятность того что клиент вам все сломает.
                                    +1
                                    Уж извините, но похоже перейду к ad hominem
                                    Менять схему шардирования на живую очень сложно и очень опастно. Потерять даннные при перешардировании как нефиг делать. Завалить все приложение еще проще.

                                    Т.е. не умееете. Я понял.

                                    На самом же деле там совсем не rocket science.
                                    Генерируете новый ключ определяющий новый шард (старый все еще работает). И или в фоновом пакетном режиме, или если нагрузка позволяет, то прямо по факту обращения к данным, или же в гибридном варианте из 1 и 2 сразу — переносите данные на новый шард (в старом вы их не удаляете, более того продолжаете их обновлять, если они там есть, а в идеале и добавлять новые).
                                    Как только у вас все старые данные будут отмечены как мигрировавшие — можете отключать старые шарды.
                                    Да — долго.
                                    Да — трудо и ресурсоемко.
                                    Но не более того.

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

                                    О чем вообще речь?
                                    О возможности получить уникальный ключ «до» вставки в базу?
                                    А можно больше подробностей из вашей личнной жизни, когда такой ключ вам всё разломал?

                                    А для начала надо обвесить костылями, мониторингами и автобанилками плохих клиентов это место. Чтобы максимально понизить вероятность того что клиент вам все сломает.

                                    Я вам открою глаза.
                                    Клиентом для БД обычно выступает backend. Зачем мне банить собственный же сервис — я не знаю.

                                    Но у вас, судя по всему, фантазия намного богаче. Поэтому перемен подробностей требуют наши сердца
                                      0
                                      Вы описали типичную схему миграции данных. Откуда угодно куда угодно.
                                      Пишем в два места, читаем из старого, копируем историю в новое по мере возможности.
                                      Когда все скопирвали постепенно катим читалку из нового. Оно еще и под нагрузкой сложится может.

                                      А теперь проверните это хотя бы для одного петабайта данных. Ладно даже для 100 терабайт подойдет.

                                      Да — долго.
                                      Да — трудо и ресурсоемко.

                                      Этого уже достаточно чтобы хотеть не делать такого никогда.

                                      А можно больше подробностей из вашей личнной жизни, когда такой ключ вам всё разломал?

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

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

                                      Я и раньше старался всеми силами избегать даже потенциального появления такого, но вот же. Недоглядел. Теперь еще сильнее стараюсь.

                                      Клиентом для БД обычно выступает backend. Зачем мне банить собственный же сервис — я не знаю.

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

                                        Именно. Если кто-то делал решардирование другим способом — то флаг ему в руки и барабан на шею.

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

                                        Минусы UUIDv5 уже перечислялись. И неудобная мнемоника для человека, и абсолютная случайность последовательности.
                                        Но вот как раз последнее и страхует от такого вот перекоса.
                                        Полностью вопрос не закрывается, потому как разработчик может начудить с вычислением ключа шарда на данных. Но тут — ой. Это проблема не идентификатора записи, который как раз уникальный.

                                        У вас очень странное понимание слова клиент. Так его больше никто не понимает. Предлагаю использовать общеупотребимые термины для обозначения вещей.


                                        Давайте вы не будете свои образы сразу на всех переносить?

                                        Клиент базы данных это приложение и/или сервис.
                                        И только в особо упоротых кошмарах мне может присниться ваша трактовка, когда пользовательское приложение (минуя все) ходит напрямую в БД по открытым всему миру портам.

                                        Во всех нормальных случаях клиент (как приложение пользователя) ходит к бекенду/серверной части и уже они (как клиент базы данных) ходят в БД.
                                        Даже если ваш продукт в особозащищенном корпоративном сегменте открытые порты БД в общую корпоративную сеть крайне не рекомендуются. И это намного более неприятно, чем последовательные айдишники с которыми спорят ниже.
                                          0
                                          Клиент базы данных это приложение и/или сервис.
                                          И только в особо упоротых кошмарах мне может присниться ваша трактовка, когда пользовательское приложение (минуя все) ходит напрямую в БД
                                          Ну это вы сами сейчас придумали. Речь шла о генерации ключей на клиенте. И ключи эти через все слои бекенда без изменений попадают в БД. И если ключ шардирования просто первые N бит UID-а, может быть проблема. Но кто мешает его прохешировать с секретной солью?

                                          Но, если более 25% клиентов захвачены злоумышленником (чтобы перекосы в шардировании стали реально на что-то влиять), у вас большие проблемы и без генерации ключей, можно и другие гадости натворить.
                                            0
                                            Речь шла о генерации ключей на клиенте.

                                            не ключей, а идентификаторов записи.

                                            Ключ, вместе с определением в какой шард писать должен формироваться несколько в другом месте.

                                            О чем я и писал
                                              0
                                              И если ключ шардирования просто первые N бит UID-а, может быть проблема. Но кто мешает его прохешировать с секретной солью?

                                              Только не в проде, только не в проде.
                                              Вы с такими шардами потом концов не найдете.

                                              Но, если более 25% клиентов захвачены злоумышленником (чтобы перекосы в шардировании стали реально на что-то влиять), у вас большие проблемы и без генерации ключей, можно и другие гадости натворить.

                                              Достаточно нескольких клиентов с говноскриптами на них. Даже не со зла. Просто кто-то из клиентов что-то решил улучшить и оптимизировать. И написал скрипт который потоком (вполне легальным по размеру) льет все в один ваш шард. Потому что ему показалось что вот так ключи генерить тоже нормально. И валидацию они проходят.
                                                0
                                                Достаточно нескольких клиентов с говноскриптами на них. Даже не со зла. Просто кто-то из клиентов что-то решил улучшить и оптимизировать. И написал скрипт который потоком (вполне легальным по размеру) льет все в один ваш шард
                                                Моя мысль была в том, что если у сервиса 1000 клиентов и один сломал ключ шардирования, то пофиг. Пусть он один пойдёт в один шард. На фоне остальных не критично.
                                                  0
                                                  Вы недооцениваете изобретательность клиентов.

                                                  И недооцениваете возможность обмена знаниями между клиентами. Один сделал скриптик и выложил его в общий доступ. Хорошее же дело, почему бы и не помочь другим?
                                                  А другие взяли его. Работает же. Даже жизнь облегчает. Надо брать.

                                                  В итоге у вас все сломалось. Просто так, не со зла. Никто не хотел навредить. Просто так вышло.

                                                  Лучше заранее обо всем таком подумать и спроектировать так чтобы подобные действия не могли вам навредить. Все равно можно что-то упустить и положить систему, но стараться в этом месте есть смысл.
                                                  Вероятность и количество потенциальных проблем можно сильно уменьшить.
                                              0
                                              Последовательные id не менее уникальны. А так же легко читаются, предсказуемы и далее по тексту.

                                              Клиент базы данных это приложение и/или сервис.
                                              И только в особо упоротых кошмарах мне может присниться ваша трактовка, когда пользовательское приложение (минуя все) ходит напрямую в БД по открытым всему миру портам.

                                              Клиент это клиент. Обычно это человек в интернете. Или сервис в сети. На нем в общем случае может быть вообще что угодно. И он может вам слать абсолютно любой мусор.
                                                0
                                                Человек никаких uuid не генерирует.

                                                Давайте тут без давайте.
                                                  0
                                                  Человек = браузер. Ну вроде типичная штука?
                                                    0
                                                    Нет. Точно так же как вы тут уже спутали массу прочих понятий.

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


                                                    Я не понимаю, почему у вас генерация ключа для шардирования оказалась в 1 и 2м случаях.
                                                    В 3м случае никого банить не надо. Обвал вашей шарды произошел по вашей же вине — вы не учли каких-то моментов в формировании ключа.
                                                    Я не скажу что вы уникальны в этом контексте, но на основании этого делать выводы о той или иной сторне в uuid vs sequence — странно.

                                                    P.S. сам я где возможно использую обычный autoincrement. И уж случай автора статьи считаю полной упоротостью.
                                                    Что, впрочем, не мешает мне понимать где uuid справился бы лучше чем sequence.
                                                      0
                                                      Клиент человек от клиента браузера или клиента скрипта с точки зрения бекендера не отличается вообще ничем.
                                                      Все потребляют джейсоны и передают джейсоны. С любой ограниченной сверху моими квотами скоростью.

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

                                                      Клиент это что угодно внешнее и не контролируемое мной.

                                                      Разработчики базы считают клиентом мой бекенд. И относятся к нему точно так же. Это логично.

                                                      Что, впрочем, не мешает мне понимать где uuid справился бы лучше чем sequence.

                                                      Я где-то в другой ветке писал. Защита не очень важных данных не очень долгое время.

                                                      Карта по которой бежит курьер. Использовать неперебираемое значение для уникальной ссылки и не защищать ее больше никак разумо. Утечет ну и ладно.
                        +1
                        Хороший сайт для старта — Use The Index, Luke. Там много информации про работу индексов «под капотом», которая сложнее «ну там просто дерево». Далее лучше смотреть документацию под вашу БД.
                      +4

                      Есть такая штука Universally Unique Lexicographically Sortable Identifier ULID


                      На тему производительности в PostgreSQL: Sequential UUID Generators, Sequential UUID Generators on SSD

                        0

                        Похожая идея в ObjectId из монго спеки bson

                        +3
                        можно использовать nanoid в браузере, у которого по умолчанию шире набор символов относительно uuid и сделать произвольное количество символов. посчитать необходимую длину для уменьшения вероятности совпадения zelark.github.io/nano-id-cc
                          +6
                          отличное решение несуществующей проблемы.
                            –3
                            Почему несуществующей?
                            Я же столкнулся
                            Разница видимо только в том, что если ты делаешь нативное приложение — проблема существует, а если сайт который сохраняется на телефон, то уже нет:)
                            –2

                            Какую же чушь пишут в комментариях. Якобы "вставка" происходит в какое-то "случайное место" и якобы надо сдвигать какие-то записи. Ни индекс, ни таблица не сделаны в виде линейного массива, неучи. Индексы в СУБД обычно делают в виде двоичных деревьев. А в таблице данные вообще могут храниться в произвольном порядке.


                            Тем не менее, на мой взгляд, UUID — абсолютно плохой и античеловеческий способ выбирать идентификаторы. Так как человеку очень трудно запоминать и сравнивать длинные последовательности случайных чисел. Захотите вы при отладке поискать в СУБД что-то по идентификатору — и надо копировать длиннющую строку. Да и воспринимать их тяжело при просмотре таблиц. URL с ними получаются уродливыми, и их тяжело перепечатывать.


                            То ли дело автоинкрементируемый id. Они небольшие и их легко можно запомнить и набрать по памяти. Это идентификатор здорового человека. Если есть возможность, выбирайте именно его.

                              +1
                              Ознакомьтесь с внутренним устройством индекса прежде чем такое говорить.
                                +1
                                А когда у вас клиент оффлайн генерирует ID вы как предлагаете его генерировать?
                                Случайно выдумывать?
                                  +2

                                  Стоит задуматься, действительно ли вам требуется генерация ID в оффлайне? Как мне кажется, уж очень редкий и специфический юзеркейс.


                                  На клиенте, как правило, если мы говорим о PWA, принято сохранять данные в локальное хранилище браузера. IndexedDB — есть все необходимые для организации хранилища инструменты. Затем, при появлении доступа к сети, сущности отправляются на сервер в фоне, а взамен вы получаете ID для использования ресурса.


                                  Но зачем вам ID, если сущность ещё не создана и, как правило, полноценно работать с ней невозможно? Тем более, что в вашем случае она вообще размещена локально, и доступа к ней кроме вас никто до момента сохранения на сервере не имеет.


                                  Я могу представить, что речь о каких-то «черновиках», которые тоже надо хранить, причём довольно продолжительное время и не факт, что черновик когда-то станет книгой. Но здесь логично напрашивается использовать специально выделенную для этого таблицу. При том как на сервере, так и на клиенте.

                                  0

                                  Числовые идентификаторы в url, это зачастую угроза безопасности приложения. Если же они ещё и автоинкементы, то ещё хуже.


                                  Особенно если вы подразумеваете "лёгкость запоминания", т.е. не особенно большие числа.


                                  А разницы в сложности запоменания большого числа, например 47783245755893 и uuid, в принципе особой нету.

                                    +1
                                    Надо просто делать нормальную безопасность.
                                    И всегда помнить что любой url без авторизации доступный дольше часа это не защита. Это видимость защиты. Гугл вас точно проиндексирует рано или поздно.
                                      0

                                      Защита это совокупность факторов. Я всецело за то чтобы всё делать правильно с нормальной безопасностью.


                                      И один из пунктов, это следовать рекомендации owasp не использовать sequential ids.

                                  –1
                                  правильное понятие таблицы — куча. и где что располагается — можно только гадать.
                                  UUID — абсолютно плохой и античеловеческий способ выбирать идентификаторы.
                                  абсолютно верное мнение.
                                  для книг достаточно bigint безнакового, хватит навсегда для реального количества книг
                                  да и поиск по такому id будет намного быстрее чем по UUID
                                  и зачем формировать id в браузере? отправить данные на сервер, сервер запишет в базу, формируя id автоинкрементный, и вернёт в браузер. счас есть для этого websocket, просто и быстро.
                                  и не надо отправлять пачкой кучу данных — достаточно построчно. можно даже по заполнении каждого поля. полная гарантия что при любом сбое в сети — введённое сохранится

                                  Ознакомьтесь с внутренним устройством индекса прежде чем такое говорить.
                                  сказанное не отрицает приведённое в ссылке,

                                  да и если будет связь между таблицами — использовать для этого длинный UUID — глупо.
                                  его всё равно надо будет индексировать…
                                    0
                                    отправить данные на сервер, сервер запишет в базу, формируя id автоинкрементный, и вернёт в браузер. счас есть для этого websocket, просто и быстро

                                    А в оффлайн как это отправить?
                                    Все затевалось, чтобы можно было это использовать как PWA в оффлайне.
                                    А оффлайн не работают даже WebSocket'ы.
                                      0

                                      В браузере свой собственный движок для хранения данных — IndexedDB. Со своим autoincrement'ом и своими особенностями функционирования, отличными от Postgres/MariaDB/Oracle/MSSQL/…


                                      IMHO, структура данных в браузере (однопользовательский режим работы с данными) не должна совпадать со структурой данных на бэкенде (многопользовательский режим работы с данными). В каком-то крайнем случае (один пользователь в проекте или отсутствие пользователей) структуры могут совпадать, но это не правило, а исключение.


                                      Более того, на фронте алгоритм работы с данными, ещё не сохранёнными на бэк (offline), должен отличаться от работы с данными, на бэке уже существующими (те уже прошли валидацию по всей совокупности данных, а не только по той, которая доступна в offline). Добавление offline в PWA — это усложнение работы примерно на порядок по отношению к обычному online-взаимодействию "клиент — сервер".


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

                                        +2

                                        А зачем для оффлайн-работы вообще генерировать какой-то id? Как только сеть появится — тогда уже синхронизироваться с бэкендом и получить все нужные id, а до тех пор работать без него или с каким-нибудь временным локальным id если сильно надо

                                      +3

                                      Кстати, уже готовится proposal по добавлению генератора uuid в стандартную библиотеку: https://github.com/tc39/proposal-uuid


                                      Также, crypto.randomUUID доступен начиная с Node.js 15 без дополнительных модулей

                                        +6
                                        Генерировать ключ для БД на клиенте вообще сильная идея.
                                        Первый залетевший дятел разрушит всю цивилизацию.

                                        И заодно. Никогда не используйте uuid в роли ключей в БД. Даже пофиг на скорость, ее часто хватает с запасом. Это античеловеческий способ. Те кто будут отлаживать или эксплуатировать софт вас проклянут.
                                          +2
                                          Генерировать ключ для БД на клиенте вообще сильная идея.

                                          Удобно.


                                          И заодно. Никогда не используйте uuid в роли ключей в БД. Даже пофиг на скорость, ее часто хватает с запасом. Это античеловеческий способ. Те кто будут отлаживать или эксплуатировать софт вас проклянут.

                                          Не вижу особых проблем с отладкой uuid(да и причем тут тип идентификаторов к отладке?), зато нет нужды делать лишний подход в базу за сиквенсом.
                                          Про подход с получением id только после вставки записи, надеюсь, говорить не придётся.

                                            +2
                                            Удобно.

                                            Конечно. До первого дятла. Вы доверяете данным клиента.

                                            Не вижу особых проблем с отладкой uuid(да и причем тут тип идентификаторов к отладке?), зато нет нужды делать лишний подход в базу за сиквенсом.

                                            Он не читается и не запоминается человеком. Человек в стене uuid'ов видит только визуальный шум. Он жрет место на экране когда на него смотришь

                                            Этот поход стоит настолько дешево что ваша производительность его и не заметит. Не там вы скорость ищите.

                                            Про подход с получением id только после вставки записи, надеюсь, говорить не придётся.

                                            Именно так и надо делать. Плюс один запрос на сервер или медленный пост с отправкой данных и ожидание id по вкусу. И то и то недорого.
                                              +1
                                              Конечно. До первого дятла. Вы доверяете данным клиента.
                                              На счёт доверия не знаю, но если данные валидировать, и вставлять через подготовленные запросы, то оно и не важно.

                                              Этот поход стоит настолько дешево что ваша производительность его и не заметит. Не там вы скорость ищите.
                                              Могу согласится с тем, что там где важна читаемость айдишек, можно и за сиквенсом сходить, скорость тут действительно не при чём.
                                              (Отвлечённо: да и может что-то уже не так, если айдишники нужно самому запоминать?)

                                              Именно так и надо делать. Плюс один запрос на сервер или медленный пост с отправкой данных и ожидание id по вкусу. И то и то недорого.
                                              Возиться в коде с nullable айдишниками, которые на самом деле обязательны, не иметь возможности проассоциировать с создаваемой записью какую-то информацию, возиться с дополнительным запросом, вот что дорого(может и не очень, но зачем если можно этого не делать благодаря одной строчки вида id = uuidv4()).
                                                0
                                                На счёт доверия не знаю, но если данные валидировать, и вставлять через подготовленные запросы, то оно и не важно.

                                                В валидациях уж сколько ошибок находили. Помните времена когда sql запросы валидировали, вместо использования параметров? Иньекции были у каждого второго.

                                                Могу согласится с тем, что там где важна читаемость айдишек, можно и за сиквенсом сходить, скорость тут действительно не при чём.
                                                (Отвлечённо: да и может что-то уже не так, если айдишники нужно самому запоминать?)

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

                                                Возиться в коде с nullable айдишниками, которые на самом деле обязательны, не иметь возможности проассоциировать с создаваемой записью какую-то информацию, возиться с дополнительным запросом, вот что дорого(может и не очень, но зачем если можно этого не делать благодаря одной строчки вида id = uuidv4()).

                                                Дополнительный запрос это не дорого. Посмотрите сколько запросов делат Хабр и перестаньте экономить на спичках.

                                                Уметь отличать данные которые сервер не подвердил от тех которые он подвердил вам все равно надо. Возится в любом случае придется. Заодно стоит безопасно сделать сразу.
                                            +2
                                            UUID, в частности для этого и предназначен — для распределенной генерации ид. Дятлы тут не при делах ))
                                              –2
                                              А зачем?
                                              Типичный sql сервер обеспечивает досточно высокую скорость генерации id для задачи автора. Запас скорости гиганский, можно считать что её хватит всегда.
                                                +1
                                                Я ничего не говорил про задачу автора. И вообще вопрос не в скорости.
                                                  –2
                                                  А глобально вам зачем? Зачем генерить id распределенно?

                                                  Почему бы не взять пачку серваков выдать каждому свой кусок диапазона от лонга и вперед. Синхронизация диапазонов на один мастер. Ему можно и неторопясь отвечать.
                                                  Это если у вас что-то размером с Гугл. Если поменьше, то и такое не нужно. Локальной генерации в БД из сиквенса с головой хватит для любого практического применения.
                                                    +1

                                                    Ок, давайте пофантазируем. Допустим, я делаю приложение, которое должно работать оффлайн. Оно генерит данные и пишет в локалькую бд, а потом синхронизируется с сервером. Айдишкт нужны чтоб работать оффлайн. Да вообще сервера может не быть, что-нить распределенное p2p.

                                                      –1
                                                      Так пусть генерирует и пишет сколько угодно. Вам все равно надо знать что вот это синхронизированно, а вот это нет.
                                                      Отсюда варианты:
                                                      Не использовать локально никаких id вообще.
                                                      Брать просто из локального сиквенса в диапазоне который не используется на сервере. Вторая половина лонга отлично подойдет. При апдейте с сервера переписывать тем что сервер прислал.
                                                      Писать в отдельное поле из локального сиквенса. Когда что-то новенькое прилетает с сервера заполнять на лету. Это точно быстрее загрузки из сети.

                                                      Что выбрать зависит от…

                                                      Да вообще сервера может не быть, что-нить распределенное p2p.

                                                      Тут только хеши. Причем те что получше. Может быть сознательное вредительство.
                                              –1
                                              Никогда не используйте uuid в роли ключей в БД


                                              Согласен, но UUID всё равно будет полезен и на него придётся создавать индекс, если хотите реализовать например идемпотентную вставку новой сущности. В этом случае клиент передаёт UUID, мы его сохраняем, но генерируем внутренний PK автоинкрементом для быстрых внутренних поисков.
                                                –1
                                                И даже тогда лучше хеш от чего-то разумного что киент передает.
                                                У него есть смысл, он привязан к данным. Его можно повторно посчитать всегда. Можно быстро понять что тебе полный дубль данных передают.
                                                  –1
                                                  Дело не в дубле данных, а в детектировании банального повтора операции в рамках некой сессии, которая идёт с какого-то клиента. Для этого нет необходимости считать кэши. Если в цепочке передачи данных обновится какой-то компонент, который теперь посылает чуть другое сообщение (например, из-за расширения API), то хэши будут разные и вы создадите логические дубли.

                                                  Конечно, тут можно возразить, «а что, если клиент пошлёт что-то другое с тем же UUID?». Тут уже надо по ситуации решать — перезаписывать оригинал или откидывать как дубликат по UUID.
                                                    +1
                                                    который теперь посылает чуть другое сообщение (например, из-за расширения API), то хэши будут разные и вы создадите логические дубли.

                                                    А как обновление связанно с изменением алгоритма или данных для хеширования?
                                                    Вы не пробовали не трогать такие вещи? А если очень надо, то менять постепенно.
                                                    Начинаем считать и слать два хеша. Старый и новый. Потом через какое-то время перестаем считать и слать старый.
                                                    Типовой подход.

                                                    Дело не в дубле данных, а в детектировании банального повтора операции в рамках некой сессии, которая идёт с какого-то клиента.

                                                    Хеш это типовой подход для определения дублей данных.
                                                    Зачем выдумывать что-то другое? Оно точно будет хуже стандартного решения.
                                                      0
                                                      Возможно мы с вами решаем разные задачи. Но для задачи «понять, что кто-то ретраится» использовать кэширование — это явный оверкил.
                                                        0
                                                        Вы явно путаете кеш и хеш.

                                                        Хеш это стандартнее и оптимальнее некуда. Их все используют для определения дублей или ретраев любых пакетов данных.

                                                        Кликхаус для вас это достататочно оптимизированный софт?
                                                        Data blocks are deduplicated. For multiple writes of the same data block (data blocks of the same size containing the same rows in the same order), the block is only written once. The reason for this is in case of network failures when the client application doesn’t know if the data was written to the DB, so the INSERT query can simply be repeated. It doesn’t matter which replica INSERTs were sent to with identical data. INSERTs are idempotent.

                                                        https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/replication/
                                                          0
                                                          нгет, не путаю.

                                                          Я могу аналогично дать ссылку на статью про Idempotency Keys от Stripe :)

                                                          Насчёт производительности — не всё в этой жизни пишется на компилируемых языках. И да, всякими контрольными суммами clickhouse решает проблему надёжной передачи данных. И он эффективно работает только при больших батчах загружаемых данных, где накладные расходы на обеспечение целостности данных сильно аммортизируются. Мы же говорим про обработку единичных запросов.
                                                            0
                                                            Я могу аналогично дать ссылку на статью про Idempotency Keys от Stripe :)

                                                            Я бы это назвал словом костыль.

                                                            Насчёт производительности — не всё в этой жизни пишется на компилируемых языках.

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

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

                                                            У любого пакета в интернете считается хеш. Несколько раз на нескольких уровнях скорее всего. Ограничения по размеру для эффективной работы гораздо ниже чем вы думаете.
                                                0
                                                Никогда не используйте uuid в роли ключей в БД.

                                                В одном из моих прошлых проектов народ решил как-то исправить это. И начал перед uuid писать префикс, типа
                                                ENTITY-743a6762-1977-45c6-8918-fc6ebab9547a
                                                И хранить в Постгре как varchar. Я так и не понял чем народ руководствовался.

                                                +1
                                                ISBN?
                                                  0
                                                  не всегда есть, не уникальный (т.к. стоит денег, некоторые издатели их тупо воруют)
                                                  0
                                                  В комментариях много дельных идей, но почему никто не хочет использовать для «уникальности» составной ключ? Например uuid книги и userId — это позволит избежать повторов, да и на клиенте легко сделать проверку не отправленных данных.
                                                  Можно, например, сделать autoincrement PK и Unique index по uuid книги и userId — тогда мы получим и просто первичный ключ, и уникальность книг в коллекции.
                                                    0
                                                    Для проверки уникальности подойдет любой хеш от данных.
                                                    Клиент не уврен что отправилось. Бывает. Заслать хеш и спросить что там по нему есть.
                                                    +1
                                                    Тут Edge впереди планеты всей, так как он отображает IP, и мы можем использовать его. Но это только в Edge. А так, как видите, многого с навигатором не навоюешь.

                                                    с каких пор в navigator есть IP?

                                                      0

                                                      Видимо сохраняет куда-то при запуске, если есть соединение.

                                                        0
                                                        куда-то

                                                        куда?

                                                      0
                                                      В моем случае на бэкенде UUID используется как первичный ключ.
                                                      Когда первые байты ключа идут по порядку больше вероятность, что новая запись встанет в конец таблицы. Даже если на клиенте будет запущена синхронизация. Ведь вряд ли юзер выполнит синхронизацию данных внесенных полгода назад и СУБД будет сдвигать половину таблицы.

                                                      Преждевременная оптимизация — корень всех зол (с) Дональд Кнут

                                                        0

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

                                                          0

                                                          Проектировать БД — безусловно. Но есть ли необходимость закладываться на детали конкретной реализации конкретной БД? Автор написал свою библиотеку генерации UUID просто потому, что он считает, что где-то какие-то записи будут потенциально записываться не в конец какой-то таблицы. При этом я нигде не вижу ответа на резонный вопрос — какой процент производительности автор выиграет от данного подхода и какой эффект это окажет на его "пет-проект по учету прочитанных книг на PWA".


                                                          Потому что без этого обоснования вся статья не нужна и ответ на вопрос в заголовке — весь фронтенд использует npm uuid.

                                                            0
                                                            какой эффект это окажет на его "пет-проект по учету прочитанных книг на PWA".

                                                            Такой, что вероятность того, что последовательно сгенерированный UUID, вставляться в таблицу будет быстрее, чем рандомно сгенерированный.
                                                            Потому что кластерные индексы требуют сортировки.

                                                              0

                                                              Во-первых, я не вижу никаких подкреплений данному утверждению. Вот например цитата с Хабра:


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

                                                              Например вставка в АВЛ-дерево будет иметь сложность O(log n) вне зависимости от случайности и последоватлеьности этого числа.


                                                              Во-вторых, мой вопрос был про реальный выигрыш, а не теоретическую демагогию. Например: "Использование моей библиотеки вместо существующего решения увеличило скорость вставки 50 новых записей в таблицу с 20кк элементов на 15%".

                                                                0

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


                                                                Для быстрой вставки делают специальные решения, а не пользуют универсальные базы.


                                                                Сейчас с приходом ssd и десятках гигабайт доступной оперативки всё сильно легче, а раньше i/o считали и в определённых случаях кластерные индексы были спасением для производительности.

                                                          0
                                                          Если нужны ID офлайн, делаем счетчик. На сервере данные храним в разрезе пользователей (а может еще и в разрезе ид клиента) (даже если данные общие, все равно записывается кто добавил запись)… и получается уникальный составной ключ без кучи заморочек…
                                                            0
                                                            А потом пользователь захочет все свое перенести воон на тот аккаунт. Взрыв, ключ развалился.

                                                            Никогда не используйте ключи связанные с чем угодно в реальном мире. Мир не настолько стабилен для этого.
                                                              +1
                                                              Перенос на другой аккаунт — это уже ненормальная ситуация, тут можно в процессе новые ключи сделать.
                                                              Это один вариант
                                                              Второй вариант, локальные ключи дополняются серверными при обмене (UUID присваивается при записи в базу и возвращаются клиенту после синхронизации) и используются в качестве основных.
                                                                0
                                                                Перенос на другой аккаунт — это уже ненормальная ситуация, тут можно в процессе новые ключи сделать.

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

                                                                Под звездочкой: На сущность есть ссылки из других sql баз. И из nosql баз тоже.
                                                                А еще она выгружается внешним системам, которые не любят дубли и с ними надо договориться.

                                                                Сделать все можно. Но если подумать заранее, то жить потом заметно проще становится.

                                                                Второй вариант, локальные ключи дополняются серверными при обмене (UUID присваивается при записи в базу и возвращаются клиенту после синхронизации) и используются в качестве основных.

                                                                А потом еще подумать.
                                                                И можно не передавать локальные ключи на сервер.
                                                                Или передавать как просто поле. Ничего не значащее. По принципу пусть лежит, может пригодится. Диски дешевые.

                                                                И приходим к нормальной схеме работы.
                                                            +1
                                                            несколько слов в защиту автора
                                                            Решил я делать свой пет-проект по учету прочитанных книг на PWA.
                                                            тут не хватает очень важного уточнения — книг прочитанных только автором, и для использования только автором и для использования на многих устройствах — и только на одном в одно время, с предварительной синхронизацией перед использованием на данном устройстве, и offline (как правило).
                                                            тут не важна скорость. автоинкрементность тут может послужить злую услугу — надо дополнительно устанавливать на каждом устройстве значение для начала инкрементации.

                                                            И тут надо обсуждать только вариант генерации самого UUID.
                                                            а все другие обсуждения — просто флуд…
                                                              –1
                                                              Одна табличка не сервере. Три колонки (юзер, дата, id книжки). Индекс по юзеру и дате.
                                                              И метод дай все новое с такой-то даты. Дату контролируем на клиенте. Первая синхронизация выкачивает все.

                                                              И второй метод пометить прочитаными вот эти книжки. Клиент его может вызывать после загрузки на сервер новых книжек и получения их id с сервера. Оверхед для такого профиля нагрузки смешной.

                                                              Это слишком просто и банально?
                                                              +1
                                                              Почитал комменты… Мда…
                                                              Вот и среди программистов выросло поколение бабулек, которым «удобнее» посчитать на счётах и занести результат в эксель.
                                                              Людям дали нормальный инструмент в виде UUID для ключей, разом решающий сомн проблем, но нет, мы же дофига умные, мы придумаем 1000 причин чтоб сделать через задницу, потому что училка в универе 20 лет назад сказала так делать или потому что так было сделано на первой работе, где базу проектировал дядечка-старпёр. Нет, серьёзно, надеюсь это просто тролли и я попался.
                                                              Один рассказывает, что не доверяет данным от клиента, поэтому UUID нового объекта (т.е. случайное число) может прийти некачественный. Поэтому клиент обратится к серверу, получит сгенерированный порядковый айдишник и тут уже даже хакнутому клиенту не отвертеться, придётся давать id нормальный!
                                                              Другой во время отладки переписывает id на бумажку, диктует их по телефону или даже запоминает. Проблема в том, что запоминать 5значные числа тоже особого смысла нет, их в отладчике обычно идентифицируют по последним 2-3 символам. Именно последним, первые совпадают. Так что UUID и тут лучше, хотя бы потому, что, если UUID нормальные, они отлично идентифицируются по первым 2-3м символам, это даже удобнее. А если брать всю таблицу с несколькими десятками тысяч записей то реально тех же 5 шестнадцатиричных символов наверняка хватит на идентификацию. И СУБД умеют в like с UUID-полями.
                                                              Третий колхозит на оффлайн клиенте/оторванном кластере вторую базу и потом при синхронизации всё заливает в основную на лету меняя айдишники. 1 багованная версия, не обновляющая при слиянии foreign key в одной таблице и в базе оказываются записи со ссылками на реально существующие но не те объекты, которые потом отлавливать через дату создания или рейндж айдишников. А если, например, запись может содержать ссылки как на уже существующие «в центре» объекты, так и на тут же в оффлайне созданные, то можно столько изобретательности в костылестроении проявить. Но главное чтоб без этих ваших UUID.
                                                              Четвёртый знает, что id нельзя выдавать в урле, поэтому UUID бесполезен… ну вообще да, нельзя, когда у тебя порядковые idшники, поэтому и придумали наружу из базы выдавать UUID'ы, которые невозможно подбирать. Поэтому даже если база содержит внутри integer-ключи, заводят внешние идентификаторы в виде UUID и кладут их рядом. Однако реально разницы никакой, вторичный ключ типа UUID будет точно таким же ключом, как и первичный, если атакующий сможет инжектнуть SQL или сформировать злой запрос через API он сделает ровно то же. Если использовать UUID как первичный ключ вместо вторичного, будет просто 1 индекс вместо 2х. Надёжнее UUID в этом плане даже не знаю что, разве что каждый id перед отдачей клиенту шифровать неизвестным клиенту ключом сессии, чтоб у разных пользователей один и тот же объект разными значениями идентифицировался.

                                                              Недостатки у UUID, конечно есть, главным образом это занимаемое место. Если база содержит много таблиц с кучей foreign ключей и 1 полем с данными, тогда накладно получается. Но из личного опыта, такие базы обычно получаются у гениев, которые изобрели уникальную расширяемую систему хранения данных в виде таблицы fieldValues FK objectId, FK fieldId и для универсальности текстовое поле value, в их случае размер UUID-полей — это меньшая из проблем.
                                                                0
                                                                function uuid() {
                                                                  const tempurl = URL.createObjectURL(new Blob());
                                                                  const uuid = tempurl.toString();
                                                                  URL.revokeObjectURL(tempurl);
                                                                  return uuid.substr(uuid.lastIndexOf('/') + 1);
                                                                }
                                                                
                                                                  0
                                                                  Стандарт не гарантирует, что полученный URL будет в формате GUID. Это может быть просто 1, 2, 3,…
                                                                  Стандарт не гарантирует, что будут разные ID на разных клиентах или даже на разных вкладках. Уникальность есть только в пределах одной страницы.
                                                                    0

                                                                    Не знаю, в каком стандарте вы смотрели, но тут явно требуют UUID


                                                                    9 Generate a UUID [RFC4122] as a string and append it to result.
                                                                      0
                                                                      Я смотрел на MDM
                                                                        +1

                                                                        А где там написано про отсутствие гарантий? Посмотрел русскую и английскую версию, не вижу такого.

                                                                          0
                                                                          Уникальность в пределах одной страницы:
                                                                          The URL lifetime is tied to the document in the window on which it was created

                                                                          А где там написано про отсутствие гарантий?

                                                                          А отсутствие гарантий, что формат UUID, и обозначает, что про это не написано.

                                                                          Непонятно, почему в MDM одно, а на w3c другое. Видимо потому, что на w3c статус документа — draft.
                                                                            0
                                                                            Тут написано про жизнь урла в пределах документа, т.е. пока документ жив по этому урлу можно что-то получить, потом он будет вести в никуда. Уникальность не при чём, собственно никакой уникальности UUID в строгом смысле не гарантирует, не существует центрального аппарата выдачи UUID'ов, который следил бы что данный UUID ещё не занят, и даже старые попытки генерить их на основе уникальных mac-адресов прекратили. Уникальность обеспечивается чисто стохастически, он случаен и при этом слишком велик чтоб на него повлиял парадокс дней рождений.
                                                                              0
                                                                              Как я понимаю, уникальность тут не нужна, поэтому она и не гарантирована.
                                                                              Если браузер будет генерить одинаковые UUID-ы типа
                                                                              00000000-0000-0000-0000-000000000000
                                                                              00000000-0000-0000-0000-000000000001
                                                                              00000000-0000-0000-0000-000000000002
                                                                              для каждой страницы, но по каждому такому uid-у будет доступен тот блоб, для которого этот uid сгенерён, то согласно документации MDN, это нормальное поведение.
                                                                              А вот для генерации ключей в другой базе, да ещё с разных клиентов, такой код использовать сомнительно. Но это по документации MDN, если рассматривать документ по ссылке выше (на w3c), уже можно.
                                                                                0

                                                                                Документация на MDN – это краткий пересказ, первоисточник находится в w3c, и MDN в своей статье на него ссылается.

                                                                                  0
                                                                                  Довольно бессмысленная реализация. Вообще, зачем может понадобиться url? Ну, наверное чтоб по нему скачать. Например передав за пределы frame'а, воркеру или даже в другое окно браузера. Будь там последовательные UUID'ы можно было бы просто перебирать и воровать данные из соседних вкладок браузера. По крайней мере это объясняет почему в спецификации именно UUID, а не просто некая уникальная строка.
                                                                            0

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

                                                                      0

                                                                      ну уж id юзера я думаю никто из вас сиквенсом не выставляет типа 1,2,3 ??? :)
                                                                      есть много мест, где в целях безопасности наплевав на удобство разработчиков необходимо использовать UUID

                                                                        0

                                                                        Например? Что плохого в сиквенсе?

                                                                          0

                                                                          банально — но злобный товарищь может знать сколько пользователей до него создано и какие у них id (ну а после него — простым методом научного втыка) и попытаться испортить вам до невозможности настроение подставляя предсказуемые id в различные запросы, а так в общем — сиквенс хороший :)

                                                                            0
                                                                            может знать сколько пользователей

                                                                            Это плохо?


                                                                            подставляя предсказуемые id в различные запросы

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

                                                                              0

                                                                              очень плохо (вы вырвали из фразы не то что важно) — потому что он знает не сколько их а конкретные значения id!


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


                                                                              в пэт-проекте можно и не париться, но в крупном проекте давать в руки злоумышленникам дополнительные знания о системе — это по-крайней мере — безответственно, многие злоумышленники увидя такое воспримут это как вызов :).


                                                                              если бы все так было просто — не писали бы гайды по безопасности, а просто писали бы — не нужно говнокодить вот простой рецепт :)


                                                                              Что бы прыгать высоко — нужно прыгать высоко! (с) американский "тренер" по прыжкам в высоту (не Виталька Кличко :) )

                                                                                0
                                                                                конкретные значения id

                                                                                Это плохо? Ну вот мой конкретный ID на Хабре — 260599, и что дальше?


                                                                                найдется таки дыра куда можно будет вставить этот id

                                                                                Значит надо дыру исправлять, а не костылями её маскировать.


                                                                                давать в руки злоумышленникам дополнительные знания о системе — это по-крайней мере — безответственно

                                                                                Безопасность через неясность — вот что на самом деле безответственно. Даже владея полной информацией об инфрастуктуре и полным доступом к исходным кодам проектов, злоумышленник не должен иметь возможности напакостить без знания паролей/ключей/токенов. И нет, UUID не должен являться таким токеном, он не для этого создавался. Не надо затыкать некомпетентность разработчиков костылями.

                                                                                  0

                                                                                  чтобы прыгать выше — нужно прыгать выше :)


                                                                                  не нужно решения, которые вам не по душе клеймить костылями — это не делает вам чести как специалисту.


                                                                                  никакой неясности UUID не порождает — он лишь снижает предсказуемость
                                                                                  свое возмущение рекомендациями можете высказать крупным компаниям которые уже набили шишки и не на пет-проектах и которые активно используют UUID в качестве ключа — думаю сами сможете взять любой крупный продукт и посмотреть

                                                                                    0

                                                                                    Что есть «крупный продукт»? Ни в одном из тех продуктов, которыми пользуюсь лично я, я подобное использование UUID не замечал.

                                                                                      0
                                                                                      Например, 1с, или Microsoft Sharepoint — все ключи в таблицах базы UID-ы
                                                                                        0

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

                                                                                          0
                                                                                          Речь о том, что использование UUID для ключей заложено в best practices у крупных компаний, и уже всё равно — большой продукт, маленький, нужна безопасность, не нужна — по умолчанию делаем ключи-UUID-ы, не ошибёмся.
                                                                                            –1

                                                                                            Очень даже ошибёмся. Угробим производительность, усложним код, снизим читабельность и так далее. Плюс получим иллюзию безопасности на фоне "злоумышленник не сможет подобрать UUID бла-бла-бла" и случайно проглядим какую-нибудь уязвимость из-за потери бдительности. Пихать UUID куда попало без явной необходимости — это нифига не best practices.

                                                                                              –1
                                                                                              Ну да, 4 байта вместо 16 — это ж 12 байт экономии. И при сравнении повлияет, 1 раз из 4х миллиардов сравнение неравных UUID потребует более 1 целочисленного сравнения.
                                                                                                0

                                                                                                Про индексы БД вы решили тактично умолчать?

                                                                                                  0
                                                                                                  Безусловно, пусть про индексы БД разработчики СУБД думают.
                                                                                                  В предельно простом случае, когда у нас есть таблица с 1 последовательным первичным ключом да, можно вообще вместо СУБД записать всё в файл и находить мгновенно без всяких индексов, размер записи*значение ключа. Но в любом минимально серьёзном случае у нас будут внешние ключи, соответственно индекс понадобится и индекс будет заполняться в случайном порядке, почти как в случае UUID. А если взять вообще реальный случай, то любые видимые извне сущности, даже если это просто строчки таблицы на одной формочке, должны иметь непоследовательные разреженные ключи + у должна быть возможность найти их в базе. В результате примерно половина таблиц получает альтернативный ключ UUID с индексом по нему, т.е. все те же радости.
                                                                                                  Нет, я допускаю, что в некоторых случаях при очень большой базе можно как-то оптимизировать производительность частых запросов с джойнами, добавив внутренний последовательный ключ, который и будет использоваться для FK в других таблицах, но это уже момент оптимизации, в таких случаях и денормализацию таблиц могут сделать, на раннем этапе это преждевременно.
                                                                                                    0
                                                                                                    пусть про индексы БД разработчики СУБД думают.

                                                                                                    Как пользователям СУБД нам тоже придётся про это думать


                                                                                                    должны иметь непоследовательные разреженные ключи

                                                                                                    Кому должны? Даже в нижеописанном случае с Parler настоящей причиной проблем является вовсе не неиспользование UUID


                                                                                                    на раннем этапе это преждевременно

                                                                                                    А на позднем этапе может оказаться уже невозможно

                                                                                                      0
                                                                                                      Как пользователям СУБД нам тоже придётся про это думать

                                                                                                      Не придётся. Оптимизация — миф, попытки в неё чаще вредят. В реальности если проблемы с производительностью будут, найдётся 1-2 места, которые обнаружатся в процессе эксплуатации и которые поднимут до приемлемого уровня. Вообще, в мире где Java вытесняется Node.js разговоры про оптимизацию обычно являются враньём, просто аргумент в пользу решения, которое уже выбрано.
                                                                                                      Я вот ради интереса поискал в гугле, насколько гуиды хуже. Нашёл несколько статей с банальными пересказами плюсов и минусов гуидов, нашёл чувака, который топил за замену гуидов на другие 128битные айдишники, в которых в старших битах таймстэмп, а в младших — рандом, нашёл самостимуляцию программиста, который предлагал взять лучшее из обоих миров сделав 2 айдишника. Чего не нашёл, так это бенчмарков.
                                                                                                      Хотя вру, нашёл один. Там чувак забенчил многократное выполнение "select 1=2" и "select uuid1=uuid2", причём uuid1 и uuid2 были строковыми константами, в которых лежали уиды отличающиеся последним символом. Хороший бенч, доказал что инты сравниваются быстрее чем почти одинаковые строки


                                                                                                      Кому должны? Даже в нижеописанном случае с Parler настоящей причиной проблем является вовсе не неиспользование UUID

                                                                                                      Как вы ловко определили причину. А вообще я согласен, конечно, настоящей причиной является то что не присоединились к канцелингу Трампа и его сторонников. Однако ошибок было много, и не последняя из них — айдишники. И нечего спорить, про айдишники написали как раз силы добра, которые украли информацию. Они, конечно, могут приврать, но особого смысла заменять одну причину удачного взлома на другую у них нет.


                                                                                                      А на позднем этапе может оказаться уже невозможно

                                                                                                      Ну как невозможно… Сложно просто, придётся 1 раз написать в SQL-консоли что-то типа


                                                                                                      alter table tab1 add seq_id int identity(1,1);
                                                                                                      alter table tab2 add tab1_fk int;
                                                                                                      update t2 
                                                                                                      set t2.tab1_fk = t1.seq_id
                                                                                                      from tab2 as t2 inner join tab1 as t1 on t2.tab1_fk_guid = t1.guid

                                                                                                      Ну и в запросы потом поправить.

                                                                                                        0
                                                                                                        в мире где Java вытесняется Node.js

                                                                                                        Поэтому я Node.js принципиально не пользую, своё залезание в Python считаю ошибкой молодости и поглядываю на Rust)


                                                                                                        Чего не нашёл, так это бенчмарков.

                                                                                                        Хороший повод для написания статьи)


                                                                                                        не последняя из них — айдишники

                                                                                                        Но и далеко не первая. То, что UUID нельзя угадать, — это, конечно, прикольно, но не должно становиться основной и тем более единственной причиной его использования. Допускаю, что, может, в Parler эти UUID и пригодились бы, однако с изначальным посылом этой ветки «по умолчанию делаем ключи-UUID-ы, не ошибёмся» всё равно соглашаться не планирую — если покопаться в различных юзкейсах, можно найти примеры, где от UUID может быть больше проблем чем пользы.


                                                                                                        Ну как невозможно… Сложно просто

                                                                                                        К сожалению или к счастью, мне не доводилось работать с достаточно крупными проектами, однако мне попадались различные кулстори о том, что даже alter table add сделать оказывается невозможно потому что всё встанет колом примерно навсегда. Так что утверждения вида «1 раз написать» я бы на всякий случай делать побоялся

                                                                                                          0
                                                                                                          К сожалению или к счастью, мне не доводилось работать с достаточно крупными проектами, однако мне попадались различные кулстори о том, что даже alter table add сделать оказывается невозможно потому что всё встанет колом примерно навсегда. Так что утверждения вида «1 раз написать» я бы на всякий случай делать побоялся

                                                                                                          Cool story, bro.
                                                                                                          Мне вот что интересно, а если речь не о скрипте, а о сбое винта или о пожаре в датацентре, например, то всё, бизнес закрываем?
                                                                                                          Бэкап у базы есть? А как он делается? Ну там полностью все данные копируются из этой неподъёмной базы? Или только инкрементальные изменения за день? Любой ответ очевидно намекает на возможность сделать данные изменения даже если простой alter table на работающей базе создаёт чрезмерную задержку.

                                                                                                            0
                                                                                                            Любой ответ очевидно намекает на возможность сделать данные изменения

                                                                                                            Не намекает. Вещи, очевидные для вас, могут быть неочевидны для других, например для меня. Ну вот есть бэкапы, есть реплики, дальше-то что?


                                                                                                            Ну или вы просто некомпетентны и пытаетесь замаскировать свою некомпетентность за абстрактными словами в стиле «очевидно намекает».

                                                                                                              0

                                                                                                              По-моему мы уже выяснили, что некомпетентны тут вы. Слухи о каких-то "встанет колом" распространяете как истину. Если все данные из базы можно скопировать за вменяемое время (полный бэкап) логично и что провести простейший "патч" при копировании должно быть возможно. Можно восстановить из бэкапа копию и провести изменения там. Если есть инкрементные бэкапы можно после изменений обработать и их.
                                                                                                              Безусловно, если тупо прямо на продакшене добавлять колонку могут быть проблемы с журналом, с транзакциями, но одновременно возможность бэкапа за вменяемое время и невозможность изменения существовать не может.

                                                                                                                0
                                                                                                                Если все данные из базы можно скопировать за вменяемое время

                                                                                                                Нельзя, размер может исчисляться терабайтами.


                                                                                                                провести простейший "патч" при копировании должно быть возможно.

                                                                                                                Как именно? Инструменты, команды, документацию, пожалуйста.


                                                                                                                Если есть инкрементные бэкапы можно после изменений обработать и их.

                                                                                                                Тот же вопрос: как именно?


                                                                                                                одновременно возможность бэкапа за вменяемое время и невозможность изменения существовать не может.

                                                                                                                Продемонстрируйте конкретный способ проведения изменения, особенно для инкрементных бэкапов.




                                                                                                                Заодно отвечу на коммент ниже:


                                                                                                                тупо скопировав таблицу

                                                                                                                Копирование будет выполняться столь же неприемлемо долго, как и alter table.


                                                                                                                Я сообщил ему что так не делается.

                                                                                                                Но до сих пор не рассказали, как же это делается на самом деле.

                                                                                                                  0
                                                                                                                  Нельзя, размер может исчисляться терабайтами.

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


                                                                                                                  Как именно? Инструменты, команды, документацию, пожалуйста.

                                                                                                                  Может ещё морду вареньем намазать? Вы будете писать безапелляционную чушь про терабайты и "встанет колом", а вам подавай с документацией? Давайте вы найдёте пример с этим самым "встанет колом" и вот прямо в этом примере вы обнаружите и решение.


                                                                                                                  Копирование будет выполняться столь же неприемлемо долго, как и alter table.

                                                                                                                  Ну если вы заранее придумали про "неприемлемо долго", тогда конечно. А если взять вменяемый случай? Решение с изменением схемы через перекачку данных в новую таблицу вполне себе используется, именно в тех случаях, когда база не позволяет поменять на месте.


                                                                                                                  Мне вот что интересно. Мы обсуждаем случай, когда база изначально сделана нормальной, а потом возникло желание добавить дополнительный последовательный ключ для оптимизации. И чтоб обосновать неправильность подобного подхода вы постоянно отодвигаете ворота, как в анекдоте про "Гиви, ты чей друг, мой или медведя". ОК, предположим у нас тот самый случай, когда таблица разрослась и как-то почистить её нельзя. Самое страшное случилось. Результат? Не получится оптимизировать. Придётся купить сервер подороже и параллельно подумать о большом рефакторинге.


                                                                                                                  А теперь рассматриваем альтернативный вариант. У нас изначальнно последовательные ключи. "Для оптимальности". И вот размер таблицы рос и нам грозит переполнение ключа, т.е. необходимо сделать то же самое фактически, поменять ключ на бигинт или тот же ууид. Причём ни отказаться от этой затеи, в отличие от предыдущего варианта, мы уже не можем, ни времени на эксперименты уже не имеем, счётчик приблизился к критическому значению. Ну так и чем последовательные айдишники лучше?

                                                                                                                    0
                                                                                                                    чушь про терабайты

                                                                                                                    Давайте уточним, вы считаете, что создать многотерабайтную базу невозможно? Или почему вы считаете это чушью? А если я умерю аппетиты и опущусь на масштаб сотен гигабайт (сути это всё равно не изменит)?


                                                                                                                    Мы обсуждаем случай, когда база изначально сделана нормальной

                                                                                                                    Если у неё UUID в качестве первичных ключей — вероятно, она изначально сделана ненормальной (за редкими исключениями).


                                                                                                                    параллельно подумать о большом рефакторинге.

                                                                                                                    Ваше предложение с перекачкой в новую таблицу тоже подразумевает неизбежный «большой рефакторинг», ведь проект должен как-то продолжать работу в процессе этой самой перекачки. Или он должен уметь работать одновременно со старой и новой таблицей, или по завершению в новой таблице будут данные устаревшие на несколько часов/дней/недель (в зависимости от масштабов трагедии).


                                                                                                                    Подобное конечно делают, но каждая такая перекачка — это целое большое событие, к которому проект может готовиться месяцами.


                                                                                                                    нам грозит переполнение ключа

                                                                                                                    Ну, это опять некомпетентность разработчиков/админов — проглядели необходимость изменить ключ и слишком поздно опомнились. Точно так же можно и «проглядеть» закончившееся свободное место на сервере БД, например. Сами по себе последовательные айдишники здесь ни в чём не виноваты.

                                                                                                                      0
                                                                                                                      Давайте уточним, вы считаете, что создать многотерабайтную базу невозможно?

                                                                                                                      Возможно. Но редко и, подозреваю, там проблемы другие вылезут гораздо раньше. Тот же бэкап.


                                                                                                                      Если у неё UUID в качестве первичных ключей — вероятно, она изначально сделана ненормальной

                                                                                                                      Это ещё надо доказать. Пока что не получается, всё какие-то умозрительные построения.


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

                                                                                                                      Господи, ну сколько можно? Вот предположим мы с вами 2 дебила-говнокодера с уровнем знания БД выпускника универа, где тему преподавала тётка, живую БД в жизни не видевшая. И у нас есть интернет со стековерфлоу + нам можно отправлять сервер в мейнтейненс на 2 часа каждые 3 дня. Более того, мы — рисковые парни, делаем всё на продакшен базе.
                                                                                                                      Как реализовать эту перекачку? Ну, предположим место на диске под вторую таблицу у нас есть. Первым делом за пару дней меняем код в сервере, смотрим чтоб запросы к БД шли через хранимки и сервер выкладываем в первый мейнтейненс.
                                                                                                                      Вторым делом смотрим на таблицу. Раз она до петабайт у нас выросла, предполагаем, что удаление у нас из неё не происходит, вместо этого есть поле типа стейт, в которое записывается флажок "удалено". Если нам не повезло и такого поля нет, ну в любом случае мы сможем найти в таблице поле, в которое можно поместить бессмысленное для бизнеслогики значение и использовать его как признак того, что строка удалена. Сделали. Создаём вторую таблицу. Дальше пишем хранимки, чтоб объединяли данные из обеих таблиц. Будет медленнее, но терпимо. Во время мейнтененца меняем хранимки. Далее батчами разумного размера перекидываем данные из одной таблицы в другую, прямо в проде, вне периода обслуживания, помечая перенесённые как "удалено". Хоть месяц нонстоп этим занимаемся. Потом дропаем таблицу источника и заливаем третью версию хранимок, в которой работа идёт с новой таблицей. Видите, решаемо, даже без использования хитрого бэдэшного кунг-фу.


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


                                                                                                                      Ну, это опять некомпетентность разработчиков/админов — проглядели необходимость изменить ключ и слишком поздно опомнились.

                                                                                                                      Вы не можете списывать неудобные случаи на вариант "это возможно только в случае некомпетентности" и потом выкидывать этот случай под предлогом что некомпетентного в такую область не пустят.

                                                                                                                        0
                                                                                                                        Тот же бэкап.

                                                                                                                        Снапшоты, репликация итп. Решаемо, в принципе.


                                                                                                                        Это ещё надо доказать. Пока что не получается, всё какие-то умозрительные построения.

                                                                                                                        Пока мы рассматриваем умозрительные ситуации — никаких доказательств и не получится. Для доказательств нужен конкретный достаточно большой проект, о котором достаточно много известно конкретного (схемы таблиц и т.п.). У меня такого нет, а у вас?


                                                                                                                        нам можно отправлять сервер в мейнтейненс на 2 часа

                                                                                                                        Если хозяин проекта позволяет его останавливать на столь долгое время без значительных потерь для себя — значит проект маленький, значит alter table займёт всего несколько секунд. Да и маленьких проектах вообще ещё не важно, какие первичные ключи там стоят. Но мы же вроде о больших проектах говорим?


                                                                                                                        В больших проектах никто вам не позволит сделать такой долгий мейнтейненс.


                                                                                                                        за пару дней меняем код

                                                                                                                        «за пару дней», ага. Отличная шутка. Вы вообще работали с проектами крупнее домашней странички васи пупкина?


                                                                                                                        Раз она до петабайт у нас выросла

                                                                                                                        Условия «до петабайт у нас выросла» и «возможен мейнтейненс на 2 часа» вряд ли могут одновременно возникнуть в реальных проектах.


                                                                                                                        Видите, решаемо

                                                                                                                        Ну да, вы всю сложность спрятали за маленькой фразой «за пару дней меняем код».


                                                                                                                        Ваши рассуждения бесконечно далеки от реальных проектов.

                                                                                                                          0
                                                                                                                          Для доказательств нужен конкретный достаточно большой проект, о котором достаточно много известно конкретного (схемы таблиц и т.п.). У меня такого нет, а у вас?

                                                                                                                          Вы троллите? Предположим, проект бы был, вы реально ждёте что кто-то бы полез править многотерабайтную базу чтоб доказать что это возможно?


                                                                                                                          Вы мне надоели.
                                                                                                                          Всё чем вы занимаетесь — глубокомысленно ковыряете в носу, предполагаете ничем не обоснованные ограничения, которые вдруг волшебным образом не ограничивают ничего кроме возможности вызвать alter table. Ну и цепляетесь к словам просто чтоб хоть что-то возразить. Я вот написал про возможность приглушить сервер на 2 часа — вы тут же радостно заявили, будто бы 2 часа никто не даст, поэтому пример — говно и вообще это не есть задача для настоящего мастера. При том, что в тексте у меня не написано ни одного действия реально требующего 2 часа, вот просто не могли этого не заметить, у меня там выкладка обновления сервера (надеюсь это-то вы не запретите?) и замена хранимок. 2 часа — это просто верхняя граница, ограничение, которое явно покажет, что времени ни на alter table, ни на перекачку данных в оффлайне действительно нет и мы вынуждены работать на горячей базе. Я привёл пример реально самый упоротый, ничего нельзя, знания о базах данных нулевые — вы докопались до заявленых от балды 2х часов.


                                                                                                                          Ну да, вы всю сложность спрятали за маленькой фразой «за пару дней меняем код».

                                                                                                                          Я напомню с чего мы начали. Речь идёт о попытке оптимизировать пару прожорливых запросов где UUID'ы предположительно действительно создают проблемы с производительностью. Я предположил, что если в проекте изначально данные берутся не через вызов хранимок, а захардкоженными sql-запросами, то эти запросы несложно перенести в базу данных внутрь хранимок за пару дней. Вы тут же начинаете мухлевать и придумываете, будто это неимоверно сложно. Нет, конечно, можно придумать проект, в котором sql-запросы генерируются на лету из сложных моделей по сложным правилам, которые писали бородатые мужики 20 лет назад и в их коде никто не разбирается, поэтому просто выделить всё в хранимки нельзя. Однако не кажется ли вам, что вы уже раз 5 перегнули палку пытаясь доказать, что простое добавление столбца — это задача неимоверной сложности?


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

                                                                                                                            0
                                                                                                                            вы реально ждёте что кто-то бы полез править многотерабайтную базу чтоб доказать что это возможно?

                                                                                                                            Ну так проводить нагрузочное тестирование в том или ином виде в любом случае надо. А если нет — тогда и разговаривать не о чем, всё равно всё останется диванными теориями.


                                                                                                                            Вы мне надоели.

                                                                                                                            Вы мне тоже. Всё, чем вы занимаетесь — живёте в своём манямирке простых васепупкинских проектов.


                                                                                                                            выкладка обновления сервера (надеюсь это-то вы не запретите?)

                                                                                                                            Запретим, конечно же! Простое обновление «в лоб» — это очередной простой на минуту-другую (или больше, в зависимости от печальности состояния проекта), который на достаточно крупном проекте сделать не позволят. Поэтому обновление должно быть постепенным, с одновременной работой двух инстансов сервера — старого и нового — и плавным бесшовным переключением между ними. А это в свою очередь накладывает ещё массу всяких интересных ограничений и наваливает тонны дополнительной работы на админов/девопсов.


                                                                                                                            можно придумать проект, в котором sql-запросы генерируются на лету из сложных моделей по сложным правилам, которые писали бородатые мужики 20 лет назад и в их коде никто не разбирается

                                                                                                                            Примерно так выглядит любой взрослый легаси-проект.


                                                                                                                            Кроме того, похожим образом могут выглядеть даже новые проекты, ведь ORM никто не отменял, так что ко всем предыдущим ограничениям добавляем ещё ограничения, присущие конкретному используемому ORM, а «2 дебила-говнокодера» в коде ORM уж точно не разберутся.


                                                                                                                            Однако не кажется ли вам, что вы уже раз 5 перегнули палку пытаясь доказать, что простое добавление столбца — это задача неимоверной сложности?

                                                                                                                            Не кажется. Это вы наоборот сильно не догибаете палку.


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

                                                                                                                            Просто повторю то, что я уже писал выше:


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

                                                                                                                              Именно поэтому вы только и делаете что добавляете условия в задачу? По-моему всё очевидно, есть очень простая задача, не стоящая выеденного яйца. Но она — единственная соломинка, ну реально, не можете же вы признать, что решения принимались просто от "всегда так делаем". Особенно после того как столько пафоса было про этих смузехлёбов, не ценящих старый добрый автоинкремент. Вот и приходится раздувать щёки и заливать про важность и серьёзность добавления столбца. При том что сами подобных баз в глаза не видели.


                                                                                                                              Запретим, конечно же! Простое обновление «в лоб» — это очередной простой на минуту-другую

                                                                                                                              Cool story bro. Так плавно сливаемся с простейшего примера перегона таблицы в другую. Возражения по существу будут? Я вполне нормально процесс описал, что с ним не так?


                                                                                                                              Примерно так выглядит любой взрослый легаси-проект.

                                                                                                                              Вот мы и пришли от допущенной мной ошибки с выбором неправильного типа ключа к "взрослоему легаси проекту". Во времена старта этого проекта UUIDы в базе хоть часто бывали? А то получится, что реально встретить проект, где дурак-разработчик неправильно выбрал UUID-ключи окажется ниже чем вероятность попасть на такой же легаси с переполнением автоинкрементного ключа.


                                                                                                                              а «2 дебила-говнокодера» в коде ORM уж точно не разберутся.

                                                                                                                              А во "взрослом ORM" нет возможности использовать хранимки, верно? И созданием view не обойтись, я прав?


                                                                                                                              Подобное конечно делают, но каждая такая перекачка — это целое большое событие, к которому проект может готовиться месяцами.

                                                                                                                              Да-да, может месяцами, да хоть годами. Но:
                                                                                                                              1) всё-таки скорее к серьёзной переработке структуры, а не уровня "добавить 1 столбец".
                                                                                                                              2) всё перечисленное касается и случая переполнения последовательного айдишника, и там это будет в разы фатальнее (по вашим же условиям, "готовиться месяцами" к переходу на бигинт)
                                                                                                                              3) сама по себе ситуация с огромной базой, да с невозможностью уйти на мейнтенанц, да с ORM и легаси, да с необходимостью выгадывать миллисекунды на обработке запроса, вы осознаёте насколько это надуманно? Кому такое счастье привалит? В остальных случаях у UUID лучше. Мы планомерно приближаемся к порядкам вероятности коллизии UUIDов.

                                                                                                                                0
                                                                                                                                Возражения по существу будут?

                                                                                                                                Они были, но вы же их называете «добавлением условий» и не принимаете.


                                                                                                                                Я вполне нормально процесс описал, что с ним не так?

                                                                                                                                То, что его невозможно осуществить в реальности. Или возможно, но очень сложно.


                                                                                                                                вы осознаёте насколько это надуманно?

                                                                                                                                Нет, любой крупный проект такой.


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

                                                                                                                                  0
                                                                                                                                  Они были, но вы же их называете «добавлением условий» и не принимаете.

                                                                                                                                  Потому что это и есть добавление условий с единствнной целью сделать предложенное решение неподходящим. Случай с остановкой на 2 часа как раз это замечательно демонстрирует вашу добросовестность, вместо рассмотрения методики и оценки вы увидели то, что вам показалось слабым местом и тут же объявили что начальные условия такое не позволяют. Хотя уход в том числе и коммерческих сайтов на обслуживание вполне себе случается.


                                                                                                                                  То, что его невозможно осуществить в реальности. Или возможно, но очень сложно

                                                                                                                                  Вы надеетесь что я не замечу что вы лжёте? Доказывайте. Только без раздувания щёк и намёков на настоящий мир, вы сдуру в самом начале признались что в жизни никогда не видели базы, в которой alter table подвисает, поэтому "любой крупный проект такой" с вашей стороны не принимается.


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


                                                                                                                                  на любые мои возражения вы опять ответите, что я «перегибаю палку»

                                                                                                                                  Этого очень просто избежать, достаточно не добавлять условия и не перегибать палку.


                                                                                                                                  Ещё раз, чтоб продемонстрировать всю вашу глупость и нечестность: мы сейчас решаем проблему оптимизации запросов в базе с UUID. Задача, которую можно вообще не делать или отложить до удобного момента с довольно резиновыми рамками. Вы добавляете дополнителньые ограничения каждый раз когда я вам предлагаю простые решения, завирая, будто эти ограничения вообще чуть ли не в каждом втором проекте.
                                                                                                                                  При этом рядом лежит и ждёт вашего внимания абсолютно такая же по сложности задача с переполнением id. Она более серьёзна. Она требует срочного решения. Она требует переработки всей базы, в отличие от UUIDов старые айдишники скоро совсем отыквятся, поэтому мы должны поменять ключи не только в тех таблицах, скорость которых мы оптимизируем, но и вообще во всех которые на них ссылаются, а также везде в коде, это дополнительный ключ мы можем игнорировать на стороне сервера приложения, вспоминая о его наличии только при написании ручных запросов, но самый главный ключ, на который всё завязано, не может измениться прозрачно для сервера. Для человека с минимальным понятием об интеллектуальной честности это всё автоматически дисквалифицирует последовательные айдишники, шутка ли, при равных условиях они дают более сложную и более срочную задачу. Но вы предпочитаете делать вид, что эту проблему не замечаете.

                                                                                                                                    0

                                                                                                                                    Пока вы продолжаете сидеть в своём манямирке, предпочитаете делать вид, что реальности не существует, и называете её «добавлением условий» — я не буду отвечать, вы всё равно мой ответ проигнорируете.

                                                                                                                                  0
                                                                                                                                  сама по себе ситуация с огромной базой, да с невозможностью уйти на мейнтенанц, да с ORM и легаси, да с необходимостью выгадывать миллисекунды на обработке запроса, вы осознаёте насколько это надуманно

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

                                                                                                                                  Ладно, миллисекунды не всегда нужны.
                                                                                                                                  Cкорее так: база должна держать требуемый qps.
                                                                                                                                    0

                                                                                                                                    Да-да, типичный проект, до обеда 5 таких забабахал.
                                                                                                                                    Вы заметили, что главные загибальщики реальности в этой теме вы и вот товарищ andreymail, как раз главные противники UUID? Вы тут продолжаете доказывать, что реально произошедший месяц назад взлом, про который сами взломщики сказали, что именно последовательные айдишники им сильно помогли, вовсе ничего не доказывает и предлагаете замену вменяемого решения лишь частично работающими костылям в виде квот. Он вот, да и вы сейчас, объявляете базы уровня серьёзной соцсети типичной ситуацией, а "очередной магазин" никому не нужным.
                                                                                                                                    Знаете чем это объясняется? Тем что UUID в качестве ключей используют редко. Просто в 99%+ реально пишущихся баз данных для магазинов и документооборотов достаточно 32битного целого ключа. И это привычнее, студент приходит на легаси проект и видит "серьёзную систему" с целочисленными ключами, фактически учится на ней, привыкает. Ему необязательно знать, что начат этот проект другим студентом, который в то время даже не знал об UUID, тот бывший студент сейчас техлид бородатый, он может и хотел бы поменять ключи, но в общем работает и норм.
                                                                                                                                    И вот все эти кодеры, привыкшие к интам, они в большистве понимают, что их решения неидеальны, что выбор был сделан по привычке или "и так сойдёт". Что если за них серьёзно возьмутся, то их система не факт что проживёт дольше Парлера. И они не спорят с преимуществами UUID, тем более они изначально знали об этих преимуществах. И среди всей этой толпы пользователей целочисленных ключей нашлось всего 2 упрямца с манией величия, неспособных ни заранее предвидеть возражение и не лезть в спор, ни признать ошибку, даже после того как их носом ткнули (в тот же парлер например).

                                                                                                                                      0
                                                                                                                                      всего 2 упрямца

                                                                                                                                      Остальным просто пофиг, сидят читают нас с попкорном. Или вообще не читают.


                                                                                                                                      ни признать ошибку, даже после того как их носом ткнули

                                                                                                                                      Это да, зря вы своих ошибок не признаёте.

                                                                                                                                        0

                                                                                                                                        Да-да, отсылки к "манямирку", к авторитету отсутствующих здесь настоящих знатоков и "нет ты" — это именно так выглядит человек не являющийся глупым упрямцем.


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

                                                                                                                                          0
                                                                                                                                          как вы предлагаете переходить на 64битные ключи?

                                                                                                                                          Никак. У меня нет идей, как выкручиваться из ситуации, когда некомпетентные люди своим бездействием довели систему до неработоспособного состояния.


                                                                                                                                          Поэтому просто повторю то, что уже писал ранее:


                                                                                                                                          Точно так же можно и «проглядеть» закончившееся свободное место на сервере БД, например. Сами по себе последовательные айдишники здесь ни в чём не виноваты.
                                                                                                                                            0

                                                                                                                                            Неудовлетворительно.
                                                                                                                                            Что значит "проглядели"?
                                                                                                                                            Вот лично вы, как проектировщик приняли решение забубенить последовательные ключи. Необязательно по глупости, вы в конце концов могли получить от заказчика неверный эстимейт количества клиентов. Прикинули, что на вашу жизнь хватит с запасом. Но сервис оказался востребованнее, каждый клиент начал создавать объекты чаще чем ожидалось, да к тому же сарафанное радио разнесло и база клиентов начала расти по экспоненте. Более того, вам повезло, сисадмин оказался не раздолбаем, он обнаружил рост таблицы вовремя, да ещё и точно оценил экспоненциальность роста и без промедления вам сообщил, у вас есть 2-3 месяца до катастрофы. Место, кстати, тоже кончалось, но докупили, с этим попроще, тем более бизнес прёт. И процессоров на СУБД. Хозяин готов и битов в айдишник докупить, вам еле удалось объяснить, что биты не продаются.


                                                                                                                                            Кто в такой ситуации некомпетентен? Вы, потому что выбрали 32битные инты вместо UUID? Или заказчик, потому что неверно оценил количество клиентов? Или сисадмин, потому что должен был обнаружить проблему не за 2-3 месяца, а за 3-4? И после назначения стрелочника что делать будем, бизнес закрывать?


                                                                                                                                            По-моему данная ситуация как раз говорит в пользу решения "всегда используй UUID для айдишников, по крайней мере переполнение не словишь".

                                                                                                                                              0
                                                                                                                                              у вас есть 2-3 месяца до катастрофы

                                                                                                                                              В таком случае времени скорее всего вполне достаточно, чтобы провести ту самую «перекачку», которую вы уже неоднократно здесь расписывали. А я вам уже отвечал, что так конечно делают, мне здесь добавить нечего. Главное — не забывать, что пункт «за пару дней меняем код» займёт не меньше месяца.


                                                                                                                                              По-моему данная ситуация как раз говорит в пользу решения

                                                                                                                                              … использовать бигинт. UUID здесь ни к чему.

                                                                                                                                                0
                                                                                                                                                В таком случае времени скорее всего вполне достаточно, чтобы провести ту самую «перекачку», которую вы уже неоднократно здесь расписывали.

                                                                                                                                                Не, недостаточно. Вы, видимо, запамятовали, что в пылу так сказать, постановили, что у нас сложная система, возможно ORM, возможно даже самописный, и отключить сервер на время перекачки нельзя ну и так далее.


                                                                                                                                                В моём варианте нормально всё, UUIDы везде, их хватит, есть несколько важных запросов которые мы хотим локально оптимизировать. Вероятно наша ORM позволяет для некоторых случаев отключить генерацию запроса и прописать руками (ну, это разумное предположение, в конце концов какой бы умной не был наш самописный ORM, уже на этапе его написания мы должны были бы предполагать, что автогенерируемые запросы не всегда решат задачу и оставить возможность реализовапть для некоторых действий работу через хранимки.)
                                                                                                                                                В вашем случае работы больше, вы не можете добавить сбоку ключ bigint, вам придётся заменять и везде, все FK. И в коде айдишники менять, вы же внутри их как-то идентифицируете, значит нужно чтоб без переполнения. А если не дай бог как у вас в коде используются универсальные функции? Придётся переводить на бигинт вообще всё. Работы больше, там где я самодовольно обещал управиться за месяц, а вы не верили, вам придётся ну хотя бы раза в два увеличить. Ой чувствую аукнется вам ваш автоинкремент.


                                                                                                                                                … использовать бигинт. UUID здесь ни к чему.

                                                                                                                                                Ну… вот и по поеданию памяти вы вышли на половину UUIDа, не получив никаких из его плюшек. А на вопрос зачем такое счастье отвечаете что мало ли чего там заказчик сказал, вы верите что миллиард — это совсем немного. А потом ещё добавляете тот же UUID в треть таблиц в качестве вторичного ключа, потому что был аудит и сказали, что отдаваемые на сторону клиента айдишники не должны быть последовательными.

                                                                                                                                                  0
                                                                                                                                                  что у нас сложная система

                                                                                                                                                  Система конечно сложная, но это ещё не обязательно значит, что за пару месяцев её не получится отрефакторить. Вот за пару дней — скорее всего не получится. А вы в своём условии предоставили запас по времени, которого может оказаться достаточно.


                                                                                                                                                  получив никаких из его плюшек

                                                                                                                                                  Так они и не нужны.


                                                                                                                                                  отдаваемые на сторону клиента айдишники не должны быть последовательными.

                                                                                                                                                  Фтопку такой некомпетентный аудит.

                                                                                                                                                    0
                                                                                                                                                    Система конечно сложная, но это ещё не обязательно значит, что за пару месяцев её не получится отрефакторить

                                                                                                                                                    Началось. Когда дело касалось замены обращений к одной-двум таблицам то это вдруг становилось невозможным. Когда собственная жопа горит, так сразу за 2 месяца весь проект отрефакторим как 2 пальца. Легаси-не легаси, орм-не орм, подтянем с другого проекта 3х джунов с сеньёром и они со всем разберутся. И бюджет на это по первой просьбе выдадут, не придётся начальника убеждать, и думать он не будет, вжух и готово всё.


                                                                                                                                                    Фтопку такой некомпетентный аудит.

                                                                                                                                                    И этот человек рассказывает про манямирок.
                                                                                                                                                    Во-первых, какое в жопу "в топку"? Не вам это решать. Вы — говнокодер, который сделал через жопу и не хочет исправлять, естественно вы будете врать о том, что всё правильно сделали, но кто же настолько глуп чтоб вам на слово поверить? Вам потребуются очень сильные аргументы чтоб защитить своё решение. Из данной темы мы видим ваши аргументы: "ээээ… оптимизация. И эта… место занимает". Про "отлаживать легче" даже не заикайтесь, это против вас сработает.
                                                                                                                                                    Более того, аудитор, будь он хоть 8 раз некомпетентен, будет прав. Парлер не даст соврать.
                                                                                                                                                    Более того, чем некомпетентнее аудитор, тем больше он будет напирать на важность тех 10 принципов, которые он буквально вчера нагуглил. А принцип "последовательные ключи наружу низзя" — это один из самых известных. О том что uuid — это решение — он тоже нагуглит. Так что придётся вам uuid добавлять.

                                                                                                                                                      0
                                                                                                                                                      Так что придётся вам uuid добавлять.
                                                                                                                                                      Разве что сбоку для отдачи наружу. Потому что переписать всё хорошо денег не дадут.
                                                                                                                                                        0
                                                                                                                                                        вжух и готово всё.

                                                                                                                                                        Этот «вжух» настолько же «реалистичный», как и все ваши предложения.


                                                                                                                                                        Не вам это решать.

                                                                                                                                                        Ну тогда я уволюсь и найду такое место работы, в котором аудит будет более компетентный и в котором не используют uuid где не надо.


                                                                                                                                                        Из данной темы мы видим ваши аргументы

                                                                                                                                                        И ваши аргументы видим тоже: «ээээ, 16 байт, ээээ, какая оптимизация, и эта, непоследовательные, можем позволить разработчикам косячить в проверках доступа». Отличная мотивация по возможности отказываться от использования uuid.


                                                                                                                                                        Больше я вам отвечать не буду, живите в своём манямирке дальше, мне реально надоело.

                                                                                                                                                          0
                                                                                                                                                          Этот «вжух» настолько же «реалистичный», как и все ваши предложения.

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


                                                                                                                                                          Ну тогда я уволюсь и найду такое место работы

                                                                                                                                                          Не сомневаюсь. Накосячить и свалить, пусть за вас кто-то другой прибирает.


                                                                                                                                                          И ваши аргументы видим тоже: «ээээ, 16 байт, ээээ, какая оптимизация, и эта, непоследовательные, можем позволить разработчикам косячить в проверках доступа».

                                                                                                                                                          Во-первых, врать нехорошо. Именно вы выше решили уволиться чтоб не отвечать на внятный аргумент про внешние id. Более того, даже признаваемая вами (но сваливаемая на каких-то "некомпетентных" админов) проблема неожиданного переполнения id, uuid'ами решена. Во-вторых, вы уже второй раз отвечаете "сам дурак" совершенно невпопад. В контексте аудита мои слова будут взвешиваться с не меньшим недоверием, но я хоть что-то вменяемое смогу ответить.


                                                                                                                                                          "можем позволить разработчикам косячить в проверках доступа"

                                                                                                                                                          Тысячелетиями люди строили многоуровневые системы защиты. В военном деле, в технике. Высшей проекторской мудростью считалось так спроектировать части системы, что даже при выходе из строя всех автоматических защит ущерб был бы снижен. В IT тоже эшелонированная защита ценится, у вас может быть со всех сторон оттестированный вебсервер, но запустите вы его всё равно в контейнере или хотя бы воспользуетесь средствами OS и запустите его от имени ограниченного пользователя. Сама операционка при загрузке процесса рандомизирует адреса, чтоб усложнить выуживание информации через возможные дыры. И только в одном месте это замечательное правило даёт сбой: в случае когда предлагается разреженными идентификаторами сделать невозможным перебор, то это неправильно, вся безопасность должна держаться на одном центральном амбарном замке. Иначе это "видимость безопасности" и "потакание косякам разработчиков".

                                                                                                                                                            +1

                                                                                                                                                            Знаете, я тут зачем-то накатал очень длинную телегу с подробными объяснениями вашей неправоты (в том числе того, что косяки админов вы почему-то пытаетесь приписать мне), но потом решил заглянуть в RFC 4122 и понял, что вся эта дискуссия была полностью бессмысленной:


                                                                                                                                                            Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation.

                                                                                                                                                            Всё. Любое обоснование использования UUID как средства повышения безопасности будет нарушать RFC.


                                                                                                                                                            Да даже при хорошем рандоме, но достаточном раздолбайстве может найтись какая-нибудь уязвимость, через которую может утечь информация о существующих UUID, и ваше «сделать невозможным перебор» превратится в бесполезную тыкву.


                                                                                                                                                            Оставьте UUID там, для чего они реально создавались — для децентрализованной генерации идентификаторов в распределённых системах. А для обычных проектов с централизованным хранилищем просто возьмите бигинт (если уж вы боитесь, что инта мало), просто покройте автотестами все кейсы проверок доступа и просто наладьте мониторинг, чтобы не пропускать грядущие проблемы — всё это всё равно нужно было бы сделать даже с UUID. И тогда никаких проблем, который обсуждались в этой ветке, никогда не наступит в принципе.


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


                                                                                                                                                            Не нужно пытаться замаскировать проблемы проекта и некомпетентность разрабов/админов неуместным использованием UUID, нарушающим RFC.

                                                                                                                                                              –1
                                                                                                                                                              что вся эта дискуссия была полностью бессмысленной:

                                                                                                                                                              Плохая попытка. Очень плохая. Я бы, например, постыдился такое написать. Ещё раз повторяю волшебное слово: Parler.
                                                                                                                                                              UUID действительно сложно подобрать. Гораздо сложнее чем, например, PIN-код от пластиковой карты, или пароль пользователя, даже если в нём больше 8 символов в разном регистре с цифрами и знаками препинания. Однако ни от того ни от другого никто не отказывается, причём в серьёзном бизнесе. Вообще, это такая типичная попытка включить дурачка через максимализм. Либо у вас всё на замке, либо утекло соединение с базой данных и хакер может сделать всё что захочет. В реале бывают ситуации, когда доступ ограничен, один украденный аккаунт с чуть более высокими правами, например, который может запрашивать данные со скоростью 1 в секунду.


                                                                                                                                                              Так что мимо. RFC, даже если бы там прямо говорилось что вообще нельзя использовать UUID никогда — ну так себе авторитетный источник. В приведённом же вами RFC вовсе не говорится что UUID бесполезны, там в рамках "лучше перебдеть" советуют не рассчитывать на невозможность угадать. Спасибо большое, действительно, выдавать наружу открытый API выдающий любые данные по UUID, наверное, не стоит. Но это не отменяет факта, что последовательные ID на несколько порядков хуже.


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

                                                                                                                                                              Ну вот в соседней ветке вам предложили ответить на один простой вопрос про правильную защиту парлер и вы моментально слились. Будь вы на месте разработчика Parler вам бы пришлось не только ответить на этот вопрос, но и самому его задать, да ещё и кучу других вопросов. Как вы думаете, вы смогли бы это сделать не ошибившись или упустив чего-то?


                                                                                                                                                              Легко давать советы типа "пишите идеальный код и тогда непредсказуемые UUIDы не понадобятся". Легко списывать фейлы данной системы на "некомпетентность". Однако вы не думали, что составной частью некомпетентности является как раз защищаемая вами идея? Вы вообще осознаёте, что вы уже написали пару десятков комментов защищая техническое решение только на основании того что оно быстрее. Я не шучу, вы много ругаете "мнимые" преимущества UUID, но всё что вами сказано в пользу последовательных ID — это их скорость. Т.е. выбирая между "ну, когда у нас будет N клиентов мы сэкономим на СУБД M долларов" и "ну, если у нас поломают то скорость выкачивания данных будет в на несколько порядков меньше + мы гораздо быстрее это обнаружим просто по числу промахов по UUID со скомпрометированных аккаунтов". Как по вашему, стоит ли экономия более хрупкой системы?


                                                                                                                                                              Кстати, если вы уж такой любитель производительности, вот вам задачка. Уже приведённый в соседней ветке пример с парлером в виде жалобы модератору. Модераторский аккаунт должен позволить просмотреть сообщение на которое жалуются и возможно ещё и ветку до него, если там цитата например. Можно сделать правильно, т.е. при попытке модером просмотреть сообщение проверять имеет ли он право и эта проверка должна включать дополнительный поиск по таблице с "выданными временными разрешениями". А это дополнительный join. Более того, в рамках DRY может возникнуть мысль использовать тот же самый механизм просмотра что везде, что значит, что все просмотры сообщений будут включать join по таблице с временно выданными разрешениями, в конце концов может же один из участников переписки переслать не только модератору, но и другому человеку? Вы уверены что мамкины оптимизаторы, которым жалко производительности на UUID, где-то в процессе эксплуатации не заметят что join по выросшей таблице стал уж очень дорогим, не отключат вообще проверку по пропагандируемому вами же принципу "если сломают так сломают"?

                                                                                                                                                                +1
                                                                                                                                                                Как мне кажется, основной довод против UUID всё же неудобство в эксплуатации и отладке.
                                                                                                                                                                Если скопировать id можно просто двойным кликом и ctrl-c, мелкие id (такие, как например группы безопасности) можно выучить наизусть (например, группа «модераторы» groupid=2) и писать руками в запросах, не обращаясь к справочникам, то с UUID-ами всё гораздо сложнее. Продуктивность страдает, вероятность ошибки выше.
                                                                                                                                                                  0

                                                                                                                                                                  Я понимаю, но мне кажется что даже это немного надуманно. Модераторов так же можно узнавать по первым 2м символам. В контексте групп коллизия и по 1 байту вряд ли произойдёт. UUID, искать можно используя like. Т.е. если убрать фактор привычки, совсем ненамного неудобнее получится.

                                                                                                                                                                    0
                                                                                                                                                                    А если я хочу добавить юзера в группу?
                                                                                                                                                                    Типа
                                                                                                                                                                    insert into UserToGroups (userId, GroupId) values (117, 2);
                                                                                                                                                                    как по 2 символам идентификаторы «узнавать»?
                                                                                                                                                                      0

                                                                                                                                                                      Ну тут да, придётся копипастить. Конечно можно и без этого, но вложенный запрос всю экономию убьёт. Однако я думал о проверке глазами в результате выдачи, такая операция почаще.
                                                                                                                                                                      Ну и я бы рутинно не добавлял SQLем пользователей в группы, плохая привычка, можно как-нибудь вечером в пятницу в update забыть where написать.

                                                                                                                                                                        0
                                                                                                                                                                        На staging почему нет… Дать себе какие-то права, не залезая в GUI
                                                                                                                                                                  0
                                                                                                                                                                  Ещё раз повторяю волшебное слово: Parler.

                                                                                                                                                                  Что Parler? Неиспользование UUID просто немного упростило работу злоумышленникам, но его использование никак не помешало бы найти использовать другие способы напакостить (или вы абсолютно точно уверены, что никаких уязвимостей не было?). Неиспользование UUID лишь поспособствовало тому, что мы об этих других способах не знаем, и это даёт вам возможность спекулировать на тему «а вот если бы UUID, ух!»


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

                                                                                                                                                                  Ну вот видите, вы сами подтвердили, что на практике достаточно просто поставить рейт-лимит и никакой UUID не нужен. Аномальный всплеск использования API будет виден на нормально настроенном мониторинге — этого достаточно, чтобы предотвратить масштабную учетку данных (а от немасштабной UUID всё равно не спасёт).


                                                                                                                                                                  и вы моментально слились.

                                                                                                                                                                  Что? Где? Про рейт-лимит уже кучу раз и так написали, от меня-то вы что ещё хотите?


                                                                                                                                                                  Как вы думаете, вы смогли бы это сделать не ошибившись или упустив чего-то?

                                                                                                                                                                  Любой разработчик уровнем выше джуниора сможет.


                                                                                                                                                                  только на основании того что оно быстрее.

                                                                                                                                                                  И удобнее, и проще в реализации.


                                                                                                                                                                  ну, если у нас поломают то скорость выкачивания данных будет в на несколько порядков меньше

                                                                                                                                                                  Рейт-лимит, блджад!


                                                                                                                                                                  мы гораздо быстрее это обнаружим просто по числу промахов

                                                                                                                                                                  Ну или по аномальному всплеску использования API, впритык упирающемуся в рейт-лимит. Вряд ли человек будет читать 60 сообщений в минуту.


                                                                                                                                                                  Как по вашему, стоит ли экономия более хрупкой системы?

                                                                                                                                                                  Да. Нужно ловить баланс между хрупкостью, удобством и производительностью, и UUID вписывается в этот баланс далеко не всегда.


                                                                                                                                                                  А это дополнительный join.

                                                                                                                                                                  join совершенно не обязателен, никто не запрещает сделать отдельный sql-запрос и положить результат в какой-нибудь быстрый кэш рядышком. Если архитектура позволяет, можно попробовать даже в JWT — тогда можно обойтись и без базы, и без кэша.


                                                                                                                                                                  в рамках DRY может возникнуть мысль использовать тот же самый механизм просмотра что везде

                                                                                                                                                                  Если мамкины некомпетентные оптимизаторы доводят DRY до абсурда, то наличие или отсутствие UUID принципиально никак не повлияет на творящийся трындец.


                                                                                                                                                                  Вы уверены что мамкины оптимизаторы, которым жалко производительности на UUID, где-то в процессе эксплуатации не заметят что join по выросшей таблице стал уж очень дорогим, не отключат вообще проверку по пропагандируемому вами же принципу "если сломают так сломают"?

                                                                                                                                                                  С учётом того, что join не обязателен — отвечать на этот вопрос нет смысла.




                                                                                                                                                                  В конце концов, на UUID же свет клином не сошёлся, есть к примеру Twitter Snowflake ID — 64-битное число (плюс производительность), в старших битах timestamp (можно сортировать), в младших битах номер инстанса (можно генерировать в распределённых системах) и sequence number (трудно угадать). Его подобрать проще чем UUID, но если начать пытаться подбирать — аномальное число промахов точно так же будет видно в мониторинге. Закодировать в base64 — будет 11 символов. Почему бы не использовать что-нибудь подобное в качестве компромисса между «небезопасными» последовательными интами и жирными неудобными UUID?

                                                                                                                                                                    0
                                                                                                                                                                    Что? Где?

                                                                                                                                                                    В вашем разговоре об отсутствии тестов в парлере. Вам предложили список возможных проблем и попросили указать, полный ли он и если нет, то чего не хватает. И вы, компетентный разработчик, тут же отказались. При этом всё что вам угрожало — что над вами посмеётся полтора анонима на форуме. В реальном Парлере из-за того что кто-то ответил неправильно на этот вопрос или вовсе его не задал компании был нанесёт ущерб на миллионы. Как после этого можно написать: "Любой разработчик уровнем выше джуниора сможет"?


                                                                                                                                                                    Неиспользование UUID просто немного упростило работу злоумышленникам, но его использование никак не помешало бы найти использовать другие способы напакостить (или вы абсолютно точно уверены, что никаких уязвимостей не было?)

                                                                                                                                                                    Может были, а может и не были. Одно мы знаем наверняка: ничего более удобного для хакеров чем последовательные айдишники в том случае не нашлось. Иначе они воспользовались бы этим, а не айдишниками.


                                                                                                                                                                    просто поставить рейт-лимит и никакой UUID не нужен.

                                                                                                                                                                    Уверены? Ну давайте пофантазируем. Вот есть модератор, ему приходит жалоба и отображается 1 страница переписки на 10 сообщений. Он смотрит и принимает решение. Закладываем на всё про всё 2 минуты. 30 таких операций в час, по 10 сообщений, 300. Рабочий день 8 часов, ну на случай аврала и переработки пусть лимит будет 10, итого 3000 сообщений с одного аккаунта. А потом вдруг упираемся в лимит. Как? А один очень трудолюбивый модератор просто делает пейджап, ничего не читает, просто сканирует за секунду что там отсутствует мат, и делает пейдждаун и дальше как обычно. А фронтендщики ничего не кэшируют, ну это у них общий код с другими местами и чтоб новые сообщения не пропускать просто заново запрашивают, но у нас в 3 раза число запросов увеличилось. Ну как бы, нестрашно, пусть будет 6 тысяч чем разбираться. Итого 6 тысяч за сутки. И, возможно, 6 тысяч не бесполезных сообщений на открытых форумах, а 6 тысяч важных данных, не факт же, что настраивая рейтлимит не срезали углы и назначили разные лимиты для разных запросов. Сравним с UUID'ами. Пусть у нас можно по миллиарду запросов в сутки с модерского аккаунта делать. Миллиард — это 2 в 30й примерно. Т.е. при переборе ууида мы теряем 30 бит. Предположим, всего объектов у нас 16 млрд, т.е. 34 бита. 122-30-34 = 58 бит случайных данных. Конечно, угадать такое просто, вот так запустив миллиард запросов мы безусловно украдём за сутки гораздо больше чем 6 тысяч в вышепреведённом случае, ага.
                                                                                                                                                                    А теперь берём реалистичный случай: рейтлимит будет в любом случае, нам же не нужно чтоб имея 100 зарегистрированных аккаунтов злоумышленник смог бы с них генерировать легитимные запросы и заддосить сервер. При наличии рейтлимита, пусть даже не 6 тысяч, а на 60 тысяч в сутки при использовании гуидов мы получаем необходимость месяцами (или годами?) сидеть и перебирать ID просто чтоб угадать 1 реальный.


                                                                                                                                                                    Ну или по аномальному всплеску использования API, впритык упирающемуся в рейт-лимит.

                                                                                                                                                                    А знаете как легко было бы обнаруживать по всплеску попыток доступа к несуществующим айдишникам?


                                                                                                                                                                    В конце концов, на UUID же свет клином не сошёлся, есть к примеру Twitter Snowflake ID — 64-битное число

                                                                                                                                                                    Вот вы уже и торгуетесь. А как же все удобства последовательных айдишников?
                                                                                                                                                                    2 причины не связываться с этим. Во-первых, пусть эти "снежинки" идут в своё блеклайвсмэттер. Мы тут за консервативные ценности, вон парлер от взлома защищаем. А во-вторых:


                                                                                                                                                                    Закодировать в base64 — будет 11 символов

                                                                                                                                                                    … Против 16 байт uuid. Т.е. заплатить почти столько же, но получить вдвое меньше битов… а зачем? Если вам нужны UUID сортируемые по начальным байтам — в современных СУБД такие тоже есть.

                                                                                                                                                                      0
                                                                                                                                                                      И вы, компетентный разработчик, тут же отказались.

                                                                                                                                                                      Потому что я, компетентный (по крайней мере относительно) разработчик, понимаю, что нужно рассматривать конкретный проект с конкретными требованиями, а не абстрактный Parler, о котором мы с вами ничего не знаем, и уж тем более ничего не знаем о его модераторской стороне. Вот дайте мне хотя бы ТЗ, а лучше код — и я подумал, что бы я как разработчик и тестировщик с этим сделал бы. А тестировать «комментарии на Хабре» я не хочу, потому что это можно делать бесконечно.


                                                                                                                                                                      И, кажется, я что-то подобное уже неоднократно говорил и в этой ветке тоже — но вы, видимо, этого до сих пор не понимаете.


                                                                                                                                                                      ничего более удобного для хакеров чем последовательные айдишники в том случае не нашлось.

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


                                                                                                                                                                      Итого 6 тысяч за сутки.

                                                                                                                                                                      Во-первых, заметьте, что это всё-таки несколько меньше, чем весь Parler целиком.


                                                                                                                                                                      Во-вторых, если модератор реально работает в это время (а если не работает, то почему аккаунт не отключен?), то он тоже ведь скачивает сообщения и обязательно заметит, что упёрся в лимит в середине рабочего дня — начнётся разбирательство, в ходе которого простенький греп access-лога покажет факт присутствия злоумышленника. Так что он даже 6 тысяч слить не успеет, если над проектом работают не последние раздолбаи. (Впрочем, если бы над проектом работали бы не раздолбаи, всего этого в принципе не случилось бы...)


                                                                                                                                                                      Сравним с UUID'ами.

                                                                                                                                                                      Теряем производительность, теряем читабельность, теряем бдительность — только ради того, чтобы можно было забить болт на нормальную проработку проверок доступа? А может, лучше нормально проработать проверку доступа, чтобы даже вышеупомянутые 6 тысяч слить не получилось? Я предпочитаю решать проблемы, а не затыкать их симптомы сомнительными костылями.


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


                                                                                                                                                                      имея 100 зарегистрированных аккаунтов

                                                                                                                                                                      Если злоумышленник умудрился получить доступ к сотне модераторских аккаунтов — у проекта проблемы гораздо серьёзнее, чем какое-то там жалкое неиспользование UUID. А если аккаунты обычные, то злоумышленник банально запросит список всех переписок этого самого аккаунта и получит все UUID готовенькими, даже перебирать не придётся.


                                                                                                                                                                      А знаете как легко было бы обнаруживать по всплеску попыток доступа к несуществующим айдишникам?

                                                                                                                                                                      А знаете как легко полностью искоренить возможность несанкционированного доступа, просто проработав его проверку? Вон вы ранее уже начали думать в правильном направлении, предлагая «дополнительный join» (хотя можно и без него, но не суть), но почему-то эту линию рассуждений решили не продолжать.


                                                                                                                                                                      И только из за-того, что вы подразумеваете отсутствие проверок доступа или её уязвимую реализацию (кажется, я уже писал про автотесты?), мы тут вынуждены костылять с мониторингом. Мониторинг это конечно хорошо и правильно, но то, что на нём держится половина безопасности — уже звоночек. А если вторая половина безопасности держится на трудности подбора UUID — это ещё один звоночек.


                                                                                                                                                                      Вот вы уже и торгуетесь.

                                                                                                                                                                      Так и думал, что вы это напишете. Ну да ладно, считайте что торгуюсь.


                                                                                                                                                                      Против 16 байт uuid.

                                                                                                                                                                      Так в базе же будет лежать 8 байт бигинта, никто не заставляет хранить base64-строку, которая будет торчать только в ссылках (см. Instagram). Экономия в два раза плюс нативная поддержка процессорами, для которых 64-битные числа как родные (я не измерял, но подозреваю, что это может дать хороший буст относительно UUID).


                                                                                                                                                                      Если вам нужны UUID сортируемые по начальным байтам

                                                                                                                                                                      Ну, лично мне не нужны никакие UUID, для «обычных» проектов у меня есть последовательные айдишники с проработанной проверкой доступа, а для «распределённых» я наверное возьму Snowflake ID (:

                                                                                                                                                                        +1
                                                                                                                                                                        Потому что я, компетентный (по крайней мере относительно) разработчик, понимаю, что нужно рассматривать конкретный проект с конкретными требованиями,

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


                                                                                                                                                                        Но повторюсь в стопицотый раз, это говорит о не очень высоком уровне компетентности разработчиков Parler

                                                                                                                                                                        И я с вами в стопицотый раз соглашусь, нет ничего более некомпетентного чем последовательные айдишники во внешнем API. Будь эти некомпетентные (и/или ограниченные в бюджете) разработчики чуть компетентнее, они бы использовали UUID. При прочих равных это было бы на порядок безопаснее.


                                                                                                                                                                        Во-первых, заметьте, что это всё-таки несколько меньше, чем весь Parler целиком.

                                                                                                                                                                        Если это персональные данные 6 тысяч человек (их тоже упёрли) то это нифига не раз плюнуть. Особенно если альтернатива — 0. Ноль против 6 тысяч, что больше?


                                                                                                                                                                        Во-вторых, если модератор реально работает в это время (а если не работает, то почему аккаунт не отключен?),

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


                                                                                                                                                                        Теряем производительность, теряем читабельность, теряем бдительность

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


                                                                                                                                                                        чтобы можно было забить болт на нормальную проработку проверок доступа?

                                                                                                                                                                        А? Кто вам сказал что можно забить болт? В Парлере вот никаких болтов не забивали.


                                                                                                                                                                        Я предпочитаю решать проблемы, а не затыкать их симптомы сомнительными костылями.

                                                                                                                                                                        Это неправда. Вот рейтлимит как средство защиты — это и есть сомнителный костыль для затычки.


                                                                                                                                                                        Кроме того, обращаю ваше внимание, что вы продолжаете нарушать RFC

                                                                                                                                                                        Сосредоточтесь, даже "компетентный разработчик" типа вас способен понять, если постарается. Я, так и быть, повторю. 1) RFC — вообще не авторитет. Это просто статья. 2) Никакого "нарушения RFC" я не допускаю, так как на уникальности UUID безопасность вовсе не зиждется.


                                                                                                                                                                        Если злоумышленник умудрился получить доступ к сотне модераторских аккаунтов

                                                                                                                                                                        "компетентному разработчику" следует починить логику. Доступ к 100 модерским аккаунтам грозит вам кражей данных, а не DDOS. Надо быть полным идиотом, чтоб получив доступ к модерским аккаунтам потратить это на то что временно положить сервис. Даже ничего не ломая, со 100 модерских аккаунтов 100 китайцев могут тупо банить всех, на кого пожалуются 100 других китайцев с обычных аккаунтов, в итоге сеть получит почти такой же удар по репутации как и после слива.
                                                                                                                                                                        Речь идёт об обычных аккаунтах, которые можно зарегистрировать свободно. Если хозяин сервиса не хочет постоянно лежать под DDOSом с обычных аккаунтов, он добавит рейтлимит. А добавив его он вряд ли отключит его для модерских. Даже если модераторам не хватит обычного лимита, увеличить их лимит не сложнее чем отключить для них выборочно. Так что мы можем предполагать, что в реальном сервисе рейтлимит будет, в сочетании с UUID это решит проблему кардинально.
                                                                                                                                                                        Так понятно?


                                                                                                                                                                        Вон вы ранее уже начали думать в правильном направлении, предлагая «дополнительный join» (хотя можно и без него, но не суть), но почему-то эту линию рассуждений решили не продолжать.

                                                                                                                                                                        Можно проблемы решать разными методами. Наконец можно загнать всех модеров в офис и пропускать модерские сессии только из интрасети. Но так как мы обсуждаем гипотетический пример мы можем предположить и некоторые причины не позволяют нам воспользоваться некоторыми решениями. И это вполне реалистично, если допустим мы решили проблему кардинально через интрасеть и это нам позволило использовать последовательные id, а потом случился карантин с удалёнкой — вполне возможна ситуация что защиту через внутренний диапазон "временно" снимут. Карантин же на 2 недели всего.
                                                                                                                                                                        Напоминаю, Парлер взломали в тот момент когда этот сервис сильно штормило. Разработчики, в момент разработки, даже представить себе не могли что произойдёт. В такие моменты, когда владелец требует сохранить работоспособность сервиса, а админы в пене пытаются хоть что-то сделать, совершенно неизвестно, какие из систем защиты окажутся неработоспособными по внешним причинам, а какие будут отключены чтоб хоть как-то работало. Потом можно будет ссылаться на некомпетентного админа, который отключил X понадеявшись на Y, хотя понятно, что Y в такой ситуации не поможет, но это не отменяет некомпетентности разработчика, который отдал наружу последовательные ID.


                                                                                                                                                                        Кстати, без дополнительного джойна может не получиться. Самый простой в лоб вариант — добавить в "сообщение" поля, которые будут заполняться одновременно с подачей жалобы.
                                                                                                                                                                        Но в реале скорее всего этого не будет. У нас же заполняется таблица "жалоба", верно?
                                                                                                                                                                        Соответственно доступ могут сначала проверять если есть жалоба на сообщение (или на сообщение из контекта) и жалобу обрабатывает данный модер. Имеем джойн. Потом, когда всё разрастётся и данный джойн станет слишком дорогим может вылезти ваша же история на тему невозможности alter table. И "оптимизаторы" просто выкинут проверку, понадеявшись на другие средства защиты.


                                                                                                                                                                        Так в базе же будет лежать 8 байт бигинта, никто не заставляет хранить base64-строку

                                                                                                                                                                        Ваше описание говорило о base64. Ну ок, base64 в базе не будет. Тогда теряем возможность искать в базе по началу id через like и появляется необходимость писать функцию преобразования в селекте. Что вы там писали про читабельность и удобство разработчиков? Это сразу стало неважно?


                                                                                                                                                                        Бигинт — это очень мало. Возьмём конкретный сноуфлейк как он описан в вики. В начале у вас таймстемп. Аж 41 бит. Если нам нужно украсть данные за определённый период, мы на основании публичных данных легко найдём рейндж в этих битах. Фактически у нас будет перебор на несколько бит из этих 41. Также легко найдём возможные машинные id, их всего 1024 может быть. Оставшиеся 12 бит (4тысячи) легко переберутся, особенно учитывая что в настоящем сноуфлейке это не рандом а последовательные. Т.е. предполагая что из 4 тысячи последовательных тратится лишь часть, а потенциальных инстанцев немного (возможно мы даже знаем конкретный, если, например, мы получили доступ к одному сообщению с данного аккаунта в этот период, вряд ли сервер сменился), реальный перебор у нас может быть вообще мизерным.


                                                                                                                                                                        Ну, лично мне не нужны никакие UUID, для «обычных» проектов у меня есть последовательные айдишники с проработанной проверкой доступа, а для «распределённых» я наверное возьму Snowflake ID (:

                                                                                                                                                                        Ну и тупо. Самое интересное что я даже знаю причину: UUID — нечто страшное длинное и строкообразное, сложно поверить, что это 2 бигинта.

                                                                                                                                                                          0
                                                                                                                                                                          я не решаюсь сказать что-то конкретное даже после того как я знаю на что была направлена атака.

                                                                                                                                                                          А вот врать, пожалуйста, не надо. Я уже неоднократно в этой и соседних ветках говорил, что перебор всех сообщений защищается нормальной проверкой доступа, а работа проверок доступа проверяется автотестами. Какие именно автотесты нужно написать — зависит от того, как именно реализована проверка. Дайте мне конкретный механизм проверки доступа — и я вам расскажу что-нибудь ещё более конкретное про неё.


                                                                                                                                                                          При прочих равных это было бы на порядок безопаснее.

                                                                                                                                                                          Если фраза «при прочих равных» подразумевает компетентных разработчиков, то безопасность не изменилась бы, потому что стояла бы нормальная проверка доступа. Если фраза «при прочих равных» подразумевает некомпетентных разработчиков, то в первую очередь нужно менять их на компетентных, а не прикрывать их некомпетентность неправильным использованием UUID, нарушающим RFC.


                                                                                                                                                                          Особенно если альтернатива — 0.

                                                                                                                                                                          Нормальная проверка доступа — и будет 0.


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

                                                                                                                                                                          Какое-то глупое передёргивание.


                                                                                                                                                                          Переименовав "полное решение проблемы" в "потерю бдительности" вы ничего не доказали.

                                                                                                                                                                          Переименовав «потерю бдительности» в «полное решение проблемы» вы тоже ничего не доказали, плюс продолжаете игнорировать тот факт, что UUID это не полное решение проблемы — список существующих UUID вполне может утечь где-нибудь, если не повезёт.


                                                                                                                                                                          Вот рейтлимит как средство защиты — это и есть сомнителный костыль для затычки.

                                                                                                                                                                          Поэтому я и пишу уже неоднократно про нормальную проверку доступа и про нормальную проверку проверки доступа с помощью автотестов.


                                                                                                                                                                          на уникальности UUID безопасность вовсе не зиждется.

                                                                                                                                                                          Тогда просто берём последовательные айдишники и живём спокойно — безопасность реализуется другими механизмами и без всяких ненужных UUID.


                                                                                                                                                                          а не DDOS.

                                                                                                                                                                          Зачем вы приплели DDOS? Мы вроде про утечки разговариваем.


                                                                                                                                                                          Речь идёт об обычных аккаунтах, которые можно зарегистрировать свободно.

                                                                                                                                                                          Пусть хоть миллион зарегистрирует, и что?


                                                                                                                                                                          в сочетании с UUID это решит проблему кардинально.

                                                                                                                                                                          Это заткнёт проблему костылём. Хоть вы и абсолютно правы в том, что трудность подбора UUID затруднит возможности слива, я ещё раз повторяю и буду до бесконечности повторять, что это — костыль, наличие или отсутствие которого никак не должно влиять на уровень безопасности в грамотно реализованном проекте. Если отсутствие UUID снижает безопасность, значит где-то в проекте засела некомпетентность, которую нужно исправлять, а не маскировать её неправильным использованием UUID, нарушающим RFC.


                                                                                                                                                                          Наконец можно загнать всех модеров в офис и пропускать модерские сессии только из интрасети.

                                                                                                                                                                          В принципе можно не загонять, а выдать модерам VPN.


                                                                                                                                                                          а потом случился карантин с удалёнкой

                                                                                                                                                                          Где-то здесь всплывает некомпетентность админов, которые не осилили VPN, да.


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

                                                                                                                                                                          Думаю, проекту в таком состоянии лучше просто сдохнуть.


                                                                                                                                                                          админа, который отключил X

                                                                                                                                                                          Интересно, как он это сделает, если без X проект просто вывалится в ошибку и перестанет работать. Ну, если разработчики компетентные и не стали писать try{return get_X();}catch(e){return ACCESS_GRANTED;} разумеется.


                                                                                                                                                                          Соответственно доступ могут сначала проверять если есть жалоба на сообщение (или на сообщение из контекта) и жалобу обрабатывает данный модер. Имеем джойн.

                                                                                                                                                                          Вам религия запрещает сделать два отдельных sql-запроса и положить их в кэш/jwt? Джойн здесь абсолютно не обязателен — я различных таблиц доступа делал уже много разных и гарантирую вам это.


                                                                                                                                                                          Кроме того, стоит на всякий случай помнить, что в общем случае на sql свет клином не сошёлся и данные могут лежать в какой-нибудь условной MongoDB, в которой джойнов не бывает.


                                                                                                                                                                          Что вы там писали про читабельность и удобство разработчиков?

                                                                                                                                                                          Ничего, перечитайте ветки повнимательнее, про like писал вовсе не я. Читабельность и удобство — для конечных пользователей, которые обмениваются ссылками (а в особо запущенных случаях диктуют их голосом по телефону), а разработчикам в норме вообще не надо ходить напрямую в базу.


                                                                                                                                                                          писать функцию преобразования в селекте.

                                                                                                                                                                          Почему бы и нет, собственно?


                                                                                                                                                                          Если нам нужно украсть данные за определённый период

                                                                                                                                                                          … вас забанят намного раньше, чем вы угадаете конкретную миллисекунду в этом таймстемпе.


                                                                                                                                                                          реальный перебор у нас может быть вообще мизерным.

                                                                                                                                                                          Быстрая прикидка в калькуляторе подсказывает мне, что речь идёт примерно о миллионах попыток. Это конечно меньше чем UUID, но всё ещё достаточно, чтобы заметить аномальное количество ошибок 404 в этом вашем мониторинге или банально упереться в рейт-лимит.


                                                                                                                                                                          в настоящем сноуфлейке это не рандом а последовательные.

                                                                                                                                                                          Да, это тот сомнительный момент, который, как мне кажется, стоит заменить на реальный рандом.

                                                                                                                                                                            0
                                                                                                                                                                            Если фраза «при прочих равных» подразумевает компетентных разработчиков, то безопасность не изменилась бы, потому что стояла бы нормальная проверка доступа.

                                                                                                                                                                            И вы опять правы. Какие к чёрту "прочие равные" если в одном случае у нас последовательные айдишники наружу? Настолько некомпетентные разрабы и во всём остальном накосячат.


                                                                                                                                                                            Если фраза «при прочих равных» подразумевает некомпетентных разработчиков, то в первую очередь нужно менять их на компетентных,

                                                                                                                                                                            Самое время рассказать вам одну мудрость. Есть такое понятие как "ответственность". Не в смысле "уголовная ответственность", а "ответственность" как свойство индивида. Так вот, оно заключается в том, что человек не срезает углы надеясь на авось и не рассматривает ситуацию "виноватым оказался не я" как удовлетворительную. Ваши причитания по поводу некомпетентных тех или некомпетентных иных — это говорит ваша безответственность. Вы не можете делать через жопу надеясь, что кто-то на другом фронте не накосячит и в итоге ваша халява не станет одним из кирпичиков приведших к катастрофе, вы не можете просто назначить "некомпетентного" и на этом закрыть вопрос.
                                                                                                                                                                            Вы, кстати, видели недавний сериал про Чернобыль? Вот там именно про это, про то как некомпетентные и безалаберные люди, не решающиеся сказать "нет" начальнику совершили кучу чудовищных ошибок. Однако кончилось всё плохо именно потому, что кто-то в начале немного сэкономил, посчитав что ну до такого уж совсем безобразия никто реактор не доведёт.


                                                                                                                                                                            Нормальная проверка доступа — и будет 0.

                                                                                                                                                                            Тогда почему вы вместо неё рейтлимит предлагали?


                                                                                                                                                                            Какое-то глупое передёргивание.

                                                                                                                                                                            Вовсе нет. Мы в данном случае наблюдаем извечную проблему горе-проектировщиков, типа "я сделаю как проще, а пускай смежники сделают как правильно". Вам неудобно копипастить гуиды, ну пускай админы всё правильно настроят и защитят. Тогда будет норм. Вы даже отмазку придумаете, типа на интах база быстрее. Ну а админ придумает другую.


                                                                                                                                                                            Переименовав «потерю бдительности» в «полное решение проблемы» вы тоже ничего не доказали

                                                                                                                                                                            Не, не катит. "Поддержание бдительности" не является задачей бизнеса, а защита от утечки — да. Я даже более того скажу, плоха та система, которой нужны герои. Но даже если принять ваше целеполагание, типа самое важное — это постоянная бдительность, можете объяснить, как это сработает? Вот есть 2 сайта, в обоих получили доступ к привилегированному аккаунту, в одном смогли через последовательные айдишники часть данных выкачать, а в другом не смогли. Вопрос, как это всё повлияет на бдительность? Типа в первом бизнес разорится, сотрудников уволят, зато они в следующий раз будут серьёзнее к безопасности относиться?


                                                                                                                                                                            Тогда просто берём последовательные айдишники и живём спокойно — безопасность реализуется другими механизмами и без всяких ненужных UUID.

                                                                                                                                                                            Вы знаете, что боковые стёкла в автомобилях специально делают такими, чтоб они разбивались на маленькие кубики и не могли отрезать голову, например? При этом безопасность дорожного движения и даже безопасность в случае аварии на этих стёклах не зиждится. Значит ли это, что зря деньи тратят, могли бы обычное оконное стекло вставить? Нет? Так почему вы продолжаете нести ахинею про ненужность UUID?


                                                                                                                                                                            Зачем вы приплели DDOS? Мы вроде про утечки разговариваем.

                                                                                                                                                                            фейспалм. В третий раз объясняю: проблема DDOS намного вероятнее кражи модерского аккаунта, поэтому с практической точки зрения невероятна ситуация, когда рейтлимита не будет. Поэтому можно считать, что в любом сервисе рейтлимит есть. Соответственно подбор UUID становится нереальным даже если сопрут не один модерский аккаунт, а тысячу. А вот без UUID даже 1 украденный модерский аккаунт позволит утащить существенное количество информации.


                                                                                                                                                                            затруднит возможности слива, я ещё раз повторяю и буду до бесконечности повторять, что это — костыль,

                                                                                                                                                                            Знаете чем мы отличаемся? Я умею думать и поэтому пытаюсь аргументировать рационально. Вы же просто бросаетесь какашками "некомпетентный", "не подчиняется RFC", "костыль". Вот как решение, которое закрывает одну проблему может являться костылём? Потому что не закрывает все остальные? Надёжный замок — костыль потому что всё равно дверь из фанеры можно разломать. Бронированная дверь — костыль, потому что можно через окно залезть. А решётки на окнах — костыль, потому что простенький замок можно отмычкой открыть. И так по кругу.


                                                                                                                                                                            В принципе можно не загонять, а выдать модерам VPN

                                                                                                                                                                            Так скорее всего и будет, модер — не бог весть какая должность, их нужно много и подешевле. Из Индии, например. Ну а модер продаст аккаунт вместе с VPN.


                                                                                                                                                                            Интересно, как он это сделает, если без X проект просто вывалится в ошибку и перестанет работать.

                                                                                                                                                                            Да мало ли как? Аврал на работе, срочно отзываем всех модеров из отгула, остальных оставляем сверхурочно, чтоб предложенная вами система деактивации аккаунтов по рабочим часам не мешала просто ставим всем начало рабочего дня в 0:0 и конец в 23:59.
                                                                                                                                                                            Или взять Парлер, мы думаем, что он неправильно обрабатывал ошибку. Но это только предположение. Хакеры сказали, что смогли "восстановить" пароль от админского аккаунта. Такое могло произойти если, например, не очень хорошо разбирающийся в коде девопс увидев что двухфакторная аутентификация отвалилась и куча юзеров не могут войти, взял да в функцию ввернул код типа
                                                                                                                                                                            if (ServiceIsBad(user.email))return AUTH_PASSED;
                                                                                                                                                                            а потом вдруг оказалось, что та же функция вызывается и при попытке сбросить пароль.


                                                                                                                                                                            Вам религия запрещает сделать два отдельных sql-запроса и положить их в кэш/jwt?

                                                                                                                                                                            А чем это лучше? Приходит рест-запрос на чтение объекта номер N, проверяем, принадлежит ли объект N пользователю или есть ли в таблице с разрешениями запись где этот пользователь получает доступ к N. Ну как бы можно и 2 запроса сделать, можно джойн прописать, результат тот же.


                                                                                                                                                                            про like писал вовсе не я.

                                                                                                                                                                            Это правда. Про like писал я. Походу никому из ненавистников UUID не пришло в голову, что можно их лайком по части искать.


                                                                                                                                                                            Почему бы и нет, собственно?

                                                                                                                                                                            Потому что select * from ... where id like 'A2B%' во время дебага чуток удобнее чем select snowflake(id), data1, data2, snowflake(fk) from ... where id = desnowflake('MWExdjJiNCc')


                                                                                                                                                                            Да, это тот сомнительный момент, который, как мне кажется, стоит заменить на реальный рандом.

                                                                                                                                                                            Нажмите F12 и введите var count = 76; var buckets = 1<<12; var prob = 1; for(var i = 0; i < count; ++i) prob*=(buckets-i)/buckets; console.log(1-prob);
                                                                                                                                                                            Парадокс дней рождений, уже 76 рандомов из 4096 возможных скорее дадут коллизию чем не дадут. Да и по чеснаку, уже второй рандом нельзя без проверки коллизий отдавать, 1/4000 — достаточно большая вероятность. Посему если делать через рандом, нужно хранить массив сгенерированых айдишников, раз в тик его очищать, при генерации смотреть что такого нету, раз это всё из многопоточки запихать весь код генерации в критическую секцию. И это для довольно сомнительной разреженности. Лучше забить на разреженность и 1 атомик счётчик с инкрементом. Ну или UUID, там вообще синхронизация межпоточная не нужна, вероятности пренебрежимо малы.


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

                                                                                                                                                                              0
                                                                                                                                                                              если в одном случае у нас последовательные айдишники наружу?

                                                                                                                                                                              В который раз мне повторить, что выбор формата айдишника не должен влиять на безопасность?


                                                                                                                                                                              Самое время рассказать вам одну мудрость.

                                                                                                                                                                              Вы всё правильно рассказываете. Надо не срезать углы и реализовывать нормальную проверку доступа, а не надеяться на «авось UUID не подберёт».


                                                                                                                                                                              люди, не решающиеся сказать "нет" начальнику

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


                                                                                                                                                                              Тогда почему вы вместо неё рейтлимит предлагали?

                                                                                                                                                                              Во-первых, не вместо. Во-вторых, одно другому не мешает.


                                                                                                                                                                              а защита от утечки — да.

                                                                                                                                                                              Для которой, внезапно, нужна поддержка бдительности.


                                                                                                                                                                              Типа в первом бизнес разорится, сотрудников уволят, зато они в следующий раз будут серьёзнее к безопасности относиться?

                                                                                                                                                                              Да, примерно так это и работает. Только вот увольнять ни в коем случае не надо: «Эта трата была инвестицией в его учебу, и глупо будет увольнять этого человека, отдавать его другой компании, после такого дорогостоящего обучения.»


                                                                                                                                                                              А у второго бизнеса злоумышленники утянут списки UUID через какую-нибудь ещё уязвимость, и он разорится ещё быстрее чем первый.


                                                                                                                                                                              Вы знаете, что боковые стёкла в автомобилях специально делают такими, чтоб они разбивались на маленькие кубики и не могли отрезать голову, например?

                                                                                                                                                                              А вы не задумывались, почему скорость автомобилей не ограничивают до 20 км/ч, чтобы попасть в серьёзную аварию в принципе не было возможности?


                                                                                                                                                                              А вот без UUID даже 1 украденный модерский аккаунт позволит утащить существенное количество информации.

                                                                                                                                                                              Проверка доступа.


                                                                                                                                                                              Надёжный замок — костыль потому что всё равно дверь из фанеры можно разломать.

                                                                                                                                                                              Да.


                                                                                                                                                                              Бронированная дверь — костыль, потому что можно через окно залезть.

                                                                                                                                                                              Да.


                                                                                                                                                                              А решётки на окнах — костыль, потому что простенький замок можно отмычкой открыть.

                                                                                                                                                                              Да.


                                                                                                                                                                              Для реальной защиты все перечисленные вещи нужно применять вместе. Плюс дополнительно положить важный документ в сейф (ещё одна проверка доступа), и ко всему этому ставить камеры и сигнализацию, на всякий случай с автономным питанием (мониторинг). И когда реальная защита построена, прятать важный документ в одной из тысяч маленьких картонных коробочек в надежде, что злоумышленник просто будет долго искать нужную коробочку, уже нет никакого смысла, лишь утомительная возня владельцу добавится.


                                                                                                                                                                              Ну а модер продаст аккаунт вместе с VPN.

                                                                                                                                                                              И со списком всех UUID, которые когда-либо прошли через него. Ой.


                                                                                                                                                                              Да мало ли как?

                                                                                                                                                                              Ну как я уже говорил, такому проекту с такими некомпетентными людьми лучше просто сдохнуть. Чем раньше, тем лучше, пока не слишком много информации утекло (где-то здесь можно вспомнить про гугл-плюс, наверное)


                                                                                                                                                                              результат тот же.

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


                                                                                                                                                                              во время дебага чуток удобнее

                                                                                                                                                                              На самом деле, я не затрагиваю эту тему, потому что не совсем понимаю, зачем в принципе ходить в базу руками. Для дебага вроде бы есть админка и логи, а если уж совсем-совсем приспичит, то один раз написать snowflake/desnowflake руки не отвалятся, думаю. По-моему это не тот момент, на который стоит делать акцент — в отличие от удобства для конечных пользователей, которым Snowflake ID придётся по душе больше чем UUID, а инкрементальные идентификаторы — ещё больше (с незначительным ущербом для безопасности — помним же про проверки доступа, да?)


                                                                                                                                                                              Парадокс дней рождений, уже 76 рандомов из 4096 возможных скорее дадут коллизию чем не дадут.

                                                                                                                                                                              76 новых объектов на одной машине за одну миллисекунду? Знаете, это пожалуй тот редкий случай, когда и в самом деле стоило бы уже взять UUID.


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

                                                                                                                                                                              Ну вот, сами уже неплохие идеи предлагаете. Правда, это тоже похоже на костыль, но тут уже надо посидеть подумать, какой именно костыль стоит выбрать — этот или всё-таки UUID.


                                                                                                                                                                              Масштабы 76 сообщений за одну миллисекунду, скорее всего, никакие последовательные айдишники уже не потянут — неужели дискуссия наконец-то подошла к использованию UUID по его прямому назначению, лол?

                                                                                                                                                                                0
                                                                                                                                                                                В который раз мне повторить, что выбор формата айдишника не должен влиять на безопасность?

                                                                                                                                                                                Кому не должен? Он по факту влияет, см. Парлер.


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

                                                                                                                                                                    0
                                                                                                                                                                    Ещё раз повторяю волшебное слово: Parler.
                                                                                                                                                                    UUID действительно сложно подобрать

                                                                                                                                                                    Я, как модератор, 100% буду иметь доступ к каким-либо спискам.
                                                                                                                                                                    Мне не нужно будет перебирать непонятные ID по порядку, я просто спаршу список и запрошу пользователей согласно этого списка.

                                                                                                                                                                    Так что проблемы там были в самом Parler, а не в том, что ID были последовательны.

                                                                                                                                                                    должен уже понять, что последовательные айдишники в принципе незащитимы.

                                                                                                                                                                    Что вы мелете?
                                                                                                                                                                      0
                                                                                                                                                                      Я, как модератор, 100% буду иметь доступ к каким-либо спискам.

                                                                                                                                                                      Может быть. А может и нет. В случае Парлера, если верить хакерам, был именно перебор.


                                                                                                                                                                      Так что проблемы там были в самом Parler, а не в том, что ID были последовательны.

                                                                                                                                                                      Как вы это разделяете?


                                                                                                                                                                      Что вы мелете?

                                                                                                                                                                      То что нет ни одного вменяемого аргумента в пользу последовательных айдишников. По крайней мере мы тут не нашли.


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

                                                                                                                                                                        0
                                                                                                                                                                        То что нет ни одного вменяемого аргумента в пользу последовательных айдишников. По крайней мере мы тут не нашли.


                                                                                                                                                                        Нет аргументов в пользу отрицания вашего бреда ниже?

                                                                                                                                                                        должен уже понять, что последовательные айдишники в принципе незащитимы.


                                                                                                                                                                        Пришел товарищ и на белом глазу начал всех убеждать что солнце соленое.
                                                                                                                                                                        И возмущается тем, что ему нехватает аргументов?

                                                                                                                                                                        Я даже не знаю как это охарактеризовать.

                                                                                                                                                                        Защита приложения это вещь несколько перпендикулярная принципу генерации уникального айди.
                                                                                                                                                                        Я не понимаю какой здоровый человек может смешать эти две вещи.
                                                                                                                                                                          +1

                                                                                                                                                                          Всё что нужно — привести 1 вменяемый аргумент в пользу последовательных айдишников или 1 вменяемый против uuidов. Пока никто не смог.


                                                                                                                                                                          Пока что наблюдаем бесконечные кривляния, фантазии на тему "а всё равно Парлер бы сломали, не так так этак" и идиотские попытки в формализм, вон внизу один чувак пытается как-то вывести плохое качество uuid'ов из RFC, но до сих пор не сформулировал, вы вот сейчас решили, что фраза


                                                                                                                                                                          Защита приложения это вещь несколько перпендикулярная принципу генерации уникального айди

                                                                                                                                                                          обладает хоть каким-то смыслом.
                                                                                                                                                                          С таким же успехом можно заявить, что защита приложения перпендикулярна строковым интерполяциям и поэтому шутка про Бобби drop table — это грязные инсинуации.

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

                                                                                                                                                                            Видите, опять проклятая математика вас подводит, вы использовали утверждение «везде», значит «везде»


                                                                                                                                                                            По контексту «везде» подразумевается везде где используется квиксорт. Причем даже тут это не абсолютное везде, что тоже видно из контекста заявления.

                                                                                                                                                                            Как вы, при отсутствии у вас логического мышления, собираетесь вообще оценивать вменяемость аргументов?

                                                                                                                                                                            Вам уже 30 раз сказали — sequence/autoincrement существенно проще в использовании на большинстве этапов. С проблемами, которые вызывают именно они сталкиваются дай бог если 1% разработчиков.
                                                                                                                                                                            При этом получить типичнейшее переполнение размера индекса в MySQL на uuid это вот «как два пальца об асфальт» — 3-4 строковых поля в которых этим самые uuid лежат (до 8й версии вы будете держать их именно там).
                                                                                                                                                                            При этом читабельность таблиц действительно ухудшается.
                                                                                                                                                                            И производительность тоже страдает.

                                                                                                                                                                            Но, естественно, обладая альтернативной логикой, оценить эти вещи как вменяемые — вы не в состоянии.

                                                                                                                                                                            Поэтому откланиваюсь и желаю вам и дальше продолжать пребывать в своем невежестве.
                                                                                                                                                            0
                                                                                                                                                            Фтопку такой некомпетентный аудит.
                                                                                                                                                            Если вы собственник, можете кого угодно в топку посылать, а потом разгребать проблемы, как у Parler.

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

                                                                                                                                                              Если у проекта отсутствуют автотесты на проверку доступа во всех имеющихся эндпоинтах, то наличие или отсутствие UUID здесь ни при чём.

                                                                                                                                                                0
                                                                                                                                                                Автотесты никак не защитят от бага, который был у Parler — прекращение проверки прав, при отвале внешнего сервиса.