ΑZ
Ага. Юзаем UNIX epoch микросекунды + оставшиеся биты рандом
можно юзать просто sequence
Size: a a a
2020 September 01
B
я вот не помню что дало больше буст, что мы сделали огромную табилцу не клатсрной или то что начали юзать секвеншил гуиды)
ΑZ
влияние было как общая деградация скорости рабаоты системы
не факт что один-два запроса покажут
не факт что один-два запроса покажут
просто мы айдишки генерим на стороне клиента. Но мы в последнее время в монге живем, так что там таких проблем нет
KR
можно юзать просто sequence
не гео-friendly
B
можно юзать просто sequence
у нас разные микросервисы генерили обжекты и их в ActiveMQ складывали с разных машин
B
там в чем беда, что разброс большой у рандомных, в разные ветки б дерева все идет
И на инсертах плоховато и на селектах. Эффективность кешей убивает
И на инсертах плоховато и на селектах. Эффективность кешей убивает
ΑZ
селекты это никак не трогает
B
особеннно когда кластерная таблица
тогда один селект ордер бай дата создания с по всему диску шерстел
тогда один селект ордер бай дата создания с по всему диску шерстел
ΑZ
инсерты да
ΑZ
особеннно когда кластерная таблица
тогда один селект ордер бай дата создания с по всему диску шерстел
тогда один селект ордер бай дата создания с по всему диску шерстел
а, ну так да
ΑZ
Можно просто без PK жить
ΑZ
UQ на айди и все
NL
кстати, есть найс трик — генерировать последовтельные гуиды
чисто рандомные очень сильно убивают БД
чисто рандомные очень сильно убивают БД
Очень плохой совет, по крайней мере для Postgres.
Разверну мысль: если придётся патицировать таблицу, то это лучше делать с рандомными ключами.
Если таблица не предполагает даже теоретического партицирования, ну скажем там просто суррогатный ключ, тогда я бы сделал просто целочисленный sequence.
Разверну мысль: если придётся патицировать таблицу, то это лучше делать с рандомными ключами.
Если таблица не предполагает даже теоретического партицирования, ну скажем там просто суррогатный ключ, тогда я бы сделал просто целочисленный sequence.
B
Очень плохой совет, по крайней мере для Postgres.
Разверну мысль: если придётся патицировать таблицу, то это лучше делать с рандомными ключами.
Если таблица не предполагает даже теоретического партицирования, ну скажем там просто суррогатный ключ, тогда я бы сделал просто целочисленный sequence.
Разверну мысль: если придётся патицировать таблицу, то это лучше делать с рандомными ключами.
Если таблица не предполагает даже теоретического партицирования, ну скажем там просто суррогатный ключ, тогда я бы сделал просто целочисленный sequence.
а вот за это я не знаю, собирался ресерчить как в потгресе сортровка гуидов работает в ближайшее время
NL
а вот за это я не знаю, собирался ресерчить как в потгресе сортровка гуидов работает в ближайшее время
Дело в том, что последовательные ключи вызывают перекос во внутренних структурах данных, так называемый skew. И если ключ генерируется последовательностью, то постгрес делает некоторые оптимизации и немного расталкивает данные, чтобы уменьшить влияние этого skew, основываясь на этом консервативном предположении.
А для отфонарного целочисленного ключа такие предположения делать не получится.
А для отфонарного целочисленного ключа такие предположения делать не получится.
B
Дело в том, что последовательные ключи вызывают перекос во внутренних структурах данных, так называемый skew. И если ключ генерируется последовательностью, то постгрес делает некоторые оптимизации и немного расталкивает данные, чтобы уменьшить влияние этого skew, основываясь на этом консервативном предположении.
А для отфонарного целочисленного ключа такие предположения делать не получится.
А для отфонарного целочисленного ключа такие предположения делать не получится.
интересно, спасибо
Ну в общем в SQL сервере индексы и так косит всегда и приходится раз в N дней делать REORGANIZE ))))
Ну в общем в SQL сервере индексы и так косит всегда и приходится раз в N дней делать REORGANIZE ))))
b
🗞 СЕГОДНЯ царь проведет лекцию на тему тактики и стратегии разработки ПО
все поздравляются с праздником запарты 1 сентября!! 🎉
сложно было придумать более символический день для того, чтобы царь провел Q&A лекцию на тему методологии разработки ПО. лекция будет проходить в моей группе, Slave labour. я буду модерировать эту встречу с обоих сторон, ad hominem будет жестоко пресекаться. лекция будет разделена на четыре части, в соответствии c опорными тезисами, приведенными ниже
⏱ 19:00 Мск
🏛 https://t.me/joinchat/BL-EvVDN-RfDTPABGspFAQ
все поздравляются с праздником запарты 1 сентября!! 🎉
сложно было придумать более символический день для того, чтобы царь провел Q&A лекцию на тему методологии разработки ПО. лекция будет проходить в моей группе, Slave labour. я буду модерировать эту встречу с обоих сторон, ad hominem будет жестоко пресекаться. лекция будет разделена на четыре части, в соответствии c опорными тезисами, приведенными ниже
⏱ 19:00 Мск
🏛 https://t.me/joinchat/BL-EvVDN-RfDTPABGspFAQ
b
опорные тезисы на лекцию Царя
1. программирование–как–искусство
сейчас многие говорят, что программирование можно считать формой вполне себе творческого выражения. одна из позиций так называемого Фп комьюнити, как я понимаю, что они де–факто делают поэзию; в таком случае, последовательная критика их методологии должна непременно принимать этот факт к сведению. посредством этой “неписанной” истины, Фп сообщество может без всякого труда отражать большинство атак, челленжей, etc. есть ли место искусству в программировании?
где находится та самая грань/градиент, что разделяет осмысленное использование компьютера на поэзию и условный макакинг?
2. создание v. преобразование (a.k.a. transformation v. generation)
в чем же принципиальная разница между этими двумя способами получения данных? как мы должны организовать свои мозги, чтобы эффективно разбирать ментальную картинку, связанную с этими двумя методами?
мне, например, очень интересно как эти два подхода встречаются в natural language processing, где мы видим по сути две противостоящие парадигмы, BERT v. GPT (трансформаторы против состязательных генераторов)
как думать об этом тем из нас, кто хочет находиться на острие?
3. смерть Си, закат эпохи низкоуровневого программирования
исходя из тех кейсов, что мы видим в programming language design комьюнити, все усилия даже в области “низкоуровневых” языков направлены на совсем другие вещи, которые казалось бы уже давно не имеют ничего общего с непосредственными вычислениями, которые мы хотим выполнить… чего стоит взглянуть только на Nim, Zig, Pony, Rust. даже если закрыть глаза на то, что часто все инновации заключаются в том, чтобы добавить ти́повый сахар поверх какой–то спижженой, что называется, нахлобучки из LLVM, все равно не покидает мысль что это все уже давно не про cистемы и давно не про знаменитый low level. конечно, есть действительно интересные языки, вроде Simit, но это исключания подтверждающие правило; действительно ли мы находимся на закате эпохи низкоуровневого программирования? нам обещали Сheckout, а мы получили, в лучшем случае, CUDA API… в чем вообще заключается ценность лоу–левела, если в индустрии на него так знаменито срут?
правда ли, что в большинстве сфер нашей индустрии, язык Си и знание этого языка стало по большей мере атрибутом имиджа, нежели чем–то, что действительно имеет смысл в контексте твоего арсенала, как инженера? для кого Си вообще может быть актуален?
4. роль коллективных нарративов в индустрии
ты несколько раз упоминал идею “противостояния”, которое продается запарте под соусом каких–то качественных изменений в методологии разработке ПО. как, например, мозилла умудрилась продать запарте Rust под соусом швабодки и “безопасности”, что само по себе феноменально! молодежь, когда я последний раз проверял, самоидентифицируется через нонконформизм, бунт, интертекстуальный coup d'état языкового пространства, но не через иллюзии теплично чистого программирования… что не так с нашей молодежью, а еще важнее то, что не так с нами??
какие еще истории бренды и Технологии™ рассказывают нам и друг другу о нас, чтобы контроллировать процесс и коммодитизировать программирование–как–труд (макакинг?)
1. программирование–как–искусство
сейчас многие говорят, что программирование можно считать формой вполне себе творческого выражения. одна из позиций так называемого Фп комьюнити, как я понимаю, что они де–факто делают поэзию; в таком случае, последовательная критика их методологии должна непременно принимать этот факт к сведению. посредством этой “неписанной” истины, Фп сообщество может без всякого труда отражать большинство атак, челленжей, etc. есть ли место искусству в программировании?
где находится та самая грань/градиент, что разделяет осмысленное использование компьютера на поэзию и условный макакинг?
2. создание v. преобразование (a.k.a. transformation v. generation)
в чем же принципиальная разница между этими двумя способами получения данных? как мы должны организовать свои мозги, чтобы эффективно разбирать ментальную картинку, связанную с этими двумя методами?
мне, например, очень интересно как эти два подхода встречаются в natural language processing, где мы видим по сути две противостоящие парадигмы, BERT v. GPT (трансформаторы против состязательных генераторов)
как думать об этом тем из нас, кто хочет находиться на острие?
3. смерть Си, закат эпохи низкоуровневого программирования
исходя из тех кейсов, что мы видим в programming language design комьюнити, все усилия даже в области “низкоуровневых” языков направлены на совсем другие вещи, которые казалось бы уже давно не имеют ничего общего с непосредственными вычислениями, которые мы хотим выполнить… чего стоит взглянуть только на Nim, Zig, Pony, Rust. даже если закрыть глаза на то, что часто все инновации заключаются в том, чтобы добавить ти́повый сахар поверх какой–то спижженой, что называется, нахлобучки из LLVM, все равно не покидает мысль что это все уже давно не про cистемы и давно не про знаменитый low level. конечно, есть действительно интересные языки, вроде Simit, но это исключания подтверждающие правило; действительно ли мы находимся на закате эпохи низкоуровневого программирования? нам обещали Сheckout, а мы получили, в лучшем случае, CUDA API… в чем вообще заключается ценность лоу–левела, если в индустрии на него так знаменито срут?
правда ли, что в большинстве сфер нашей индустрии, язык Си и знание этого языка стало по большей мере атрибутом имиджа, нежели чем–то, что действительно имеет смысл в контексте твоего арсенала, как инженера? для кого Си вообще может быть актуален?
4. роль коллективных нарративов в индустрии
ты несколько раз упоминал идею “противостояния”, которое продается запарте под соусом каких–то качественных изменений в методологии разработке ПО. как, например, мозилла умудрилась продать запарте Rust под соусом швабодки и “безопасности”, что само по себе феноменально! молодежь, когда я последний раз проверял, самоидентифицируется через нонконформизм, бунт, интертекстуальный coup d'état языкового пространства, но не через иллюзии теплично чистого программирования… что не так с нашей молодежью, а еще важнее то, что не так с нами??
какие еще истории бренды и Технологии™ рассказывают нам и друг другу о нас, чтобы контроллировать процесс и коммодитизировать программирование–как–труд (макакинг?)
С
опорные тезисы на лекцию Царя
1. программирование–как–искусство
сейчас многие говорят, что программирование можно считать формой вполне себе творческого выражения. одна из позиций так называемого Фп комьюнити, как я понимаю, что они де–факто делают поэзию; в таком случае, последовательная критика их методологии должна непременно принимать этот факт к сведению. посредством этой “неписанной” истины, Фп сообщество может без всякого труда отражать большинство атак, челленжей, etc. есть ли место искусству в программировании?
где находится та самая грань/градиент, что разделяет осмысленное использование компьютера на поэзию и условный макакинг?
2. создание v. преобразование (a.k.a. transformation v. generation)
в чем же принципиальная разница между этими двумя способами получения данных? как мы должны организовать свои мозги, чтобы эффективно разбирать ментальную картинку, связанную с этими двумя методами?
мне, например, очень интересно как эти два подхода встречаются в natural language processing, где мы видим по сути две противостоящие парадигмы, BERT v. GPT (трансформаторы против состязательных генераторов)
как думать об этом тем из нас, кто хочет находиться на острие?
3. смерть Си, закат эпохи низкоуровневого программирования
исходя из тех кейсов, что мы видим в programming language design комьюнити, все усилия даже в области “низкоуровневых” языков направлены на совсем другие вещи, которые казалось бы уже давно не имеют ничего общего с непосредственными вычислениями, которые мы хотим выполнить… чего стоит взглянуть только на Nim, Zig, Pony, Rust. даже если закрыть глаза на то, что часто все инновации заключаются в том, чтобы добавить ти́повый сахар поверх какой–то спижженой, что называется, нахлобучки из LLVM, все равно не покидает мысль что это все уже давно не про cистемы и давно не про знаменитый low level. конечно, есть действительно интересные языки, вроде Simit, но это исключания подтверждающие правило; действительно ли мы находимся на закате эпохи низкоуровневого программирования? нам обещали Сheckout, а мы получили, в лучшем случае, CUDA API… в чем вообще заключается ценность лоу–левела, если в индустрии на него так знаменито срут?
правда ли, что в большинстве сфер нашей индустрии, язык Си и знание этого языка стало по большей мере атрибутом имиджа, нежели чем–то, что действительно имеет смысл в контексте твоего арсенала, как инженера? для кого Си вообще может быть актуален?
4. роль коллективных нарративов в индустрии
ты несколько раз упоминал идею “противостояния”, которое продается запарте под соусом каких–то качественных изменений в методологии разработке ПО. как, например, мозилла умудрилась продать запарте Rust под соусом швабодки и “безопасности”, что само по себе феноменально! молодежь, когда я последний раз проверял, самоидентифицируется через нонконформизм, бунт, интертекстуальный coup d'état языкового пространства, но не через иллюзии теплично чистого программирования… что не так с нашей молодежью, а еще важнее то, что не так с нами??
какие еще истории бренды и Технологии™ рассказывают нам и друг другу о нас, чтобы контроллировать процесс и коммодитизировать программирование–как–труд (макакинг?)
1. программирование–как–искусство
сейчас многие говорят, что программирование можно считать формой вполне себе творческого выражения. одна из позиций так называемого Фп комьюнити, как я понимаю, что они де–факто делают поэзию; в таком случае, последовательная критика их методологии должна непременно принимать этот факт к сведению. посредством этой “неписанной” истины, Фп сообщество может без всякого труда отражать большинство атак, челленжей, etc. есть ли место искусству в программировании?
где находится та самая грань/градиент, что разделяет осмысленное использование компьютера на поэзию и условный макакинг?
2. создание v. преобразование (a.k.a. transformation v. generation)
в чем же принципиальная разница между этими двумя способами получения данных? как мы должны организовать свои мозги, чтобы эффективно разбирать ментальную картинку, связанную с этими двумя методами?
мне, например, очень интересно как эти два подхода встречаются в natural language processing, где мы видим по сути две противостоящие парадигмы, BERT v. GPT (трансформаторы против состязательных генераторов)
как думать об этом тем из нас, кто хочет находиться на острие?
3. смерть Си, закат эпохи низкоуровневого программирования
исходя из тех кейсов, что мы видим в programming language design комьюнити, все усилия даже в области “низкоуровневых” языков направлены на совсем другие вещи, которые казалось бы уже давно не имеют ничего общего с непосредственными вычислениями, которые мы хотим выполнить… чего стоит взглянуть только на Nim, Zig, Pony, Rust. даже если закрыть глаза на то, что часто все инновации заключаются в том, чтобы добавить ти́повый сахар поверх какой–то спижженой, что называется, нахлобучки из LLVM, все равно не покидает мысль что это все уже давно не про cистемы и давно не про знаменитый low level. конечно, есть действительно интересные языки, вроде Simit, но это исключания подтверждающие правило; действительно ли мы находимся на закате эпохи низкоуровневого программирования? нам обещали Сheckout, а мы получили, в лучшем случае, CUDA API… в чем вообще заключается ценность лоу–левела, если в индустрии на него так знаменито срут?
правда ли, что в большинстве сфер нашей индустрии, язык Си и знание этого языка стало по большей мере атрибутом имиджа, нежели чем–то, что действительно имеет смысл в контексте твоего арсенала, как инженера? для кого Си вообще может быть актуален?
4. роль коллективных нарративов в индустрии
ты несколько раз упоминал идею “противостояния”, которое продается запарте под соусом каких–то качественных изменений в методологии разработке ПО. как, например, мозилла умудрилась продать запарте Rust под соусом швабодки и “безопасности”, что само по себе феноменально! молодежь, когда я последний раз проверял, самоидентифицируется через нонконформизм, бунт, интертекстуальный coup d'état языкового пространства, но не через иллюзии теплично чистого программирования… что не так с нашей молодежью, а еще важнее то, что не так с нами??
какие еще истории бренды и Технологии™ рассказывают нам и друг другу о нас, чтобы контроллировать процесс и коммодитизировать программирование–как–труд (макакинг?)
Можно попросить тебя переписать этот текст?
b
Можно попросить тебя переписать этот текст?
зачем?