Ну я тоже многое пилю сам, но типа бут лоадер, ОС, СУБД, IDE , и тп сам не пытаюсь писать, хотя ранее и это пытался. Вот и не пойму в чем у Вас прикол писать именно это, ведь есть тоже удобные надстройки.
Но Вы ответить не можете по существу. Почему 1Мб ок, а 3Мб не ок, вроде был простой вопрос, а в ответ я услышал "я есть там, я есть сям". То что Вас читают ничего не значит. Пескова и Путена тоже миллионы слушают, но верят не все.
По Вашему мнению топовость определят правость? (и кстати, у меня не все статьи и коменты в минус, а коменты в минус так и вообще ничего не значат, их в основном оценивали под эмоциями, как Вы сейчас).
Типа я могу назвать статью "как ходить в туалет" и это оправдает мои подробные описания как я туда сходил? Тут Хабр! как никак, все хотят стать крутыми и богатыми, а не узнать как вы там сходили в то что в теме указали.
В Вашем профиле Хабра я не нашел прямых ссылок на Pikabu и DTF, поэтому сочту Вашу манеру изложения как просто "понты", ну типа "я есть там, я есть сям, поэтому думайте что я крутой", про LibGDX Вы тоже не ответили по существу, почему Вам 1Мб доставляет, а уже аж целых 3Мб противны.
Ну в engine же важно не то, что он просто есть, а то, какое комьюнити, сколько багов исправлено в движке, есть ли поддержка, есть ли перспективы.
Например LibGDX помимо Android может делать сборки для desktop, для webGL, а не так давно мог и для iOS.
Я тоже много что программирую довольно давно, и СУБД свою делал и ОР-маппер, и поисковик для интернет, но это никому не нужно, решение развивается только если есть большое комьюнити. Иначе получается типа "я на asm написал крутую прогу резидентную для DOS зацените пацаны, CRLT-ALT-DEL перехватываю", но это же чисто фан без практической пользы для бизнеса или для комьюнити.
А зачем тогда это нужно "оценить количество строк при join по FK"? Это число (количество строк) потом как используется? Я понял, что для производительности, чтобы план более оптимальный, например, выбрать. Если я неправильно понял, то поясните зачем это число нужно.
Формально база не консистентна, с этим согласен. Но тут есть важный момент, консистентность ради консистентности нужна разве что студентам, чтобы лабу сдать. Так же как и производительность ради производительности. В моем случае пользователь никогда не узнает об этой неконсистентности, так как вытащить коменты можно только при наличии топика, нет топика, значит нет доступа к комментам удаленного топика. К какой то значимой утечке диского пространства это тоже не приводит.
В рамках моей бизнес логики база "условно консистентна". Это очень удачный компромис между целостностью и производительностью.
А понимаете Вы меня неправильно! Я утверждаю другое.
Если эта информация не Ваш домысел, а из документации Postgres, то скиньте ссылку пожалуйста, просвещусь. Я реально не знаю о том и не понимаю, как наличие FK может ускорить join.
Ну, про индекс написано в плане выполнения запроса, если он есть то будет index scan и будет быстро, если его нет будет seq scan и будет медленно. А вот наличие или отсутствие FK ни как не влияет на быстро/медленно. Или я не прав?
Но чтобы эту "только одну" быстро найти нужен именно индекс, а не FK. В этом можно убедиться если посмотреть план выполнения запроса, что используется именно индекс, а не FK. Или нет?
Мне просто сам принцип непонятен, как FK может помочь при джойне. Я понимаю индексы - это да, я понимаю что в СУБД индексы могут автоматически создаваться при создании FK, но чтобы FK без индекса как-то помогал такого не знаю.
За что минусуют не пойму. Я же не топлю за то что FK - это однозначное зло. С академической точки зрения FK вещь красивая и полезная, но когда разработчикам надо больше производительности приходится чем то жертвовать, так и появляются всякие NoSQL, дроп констрейнтов и т.п. Я просто делюсь своим опытом, и считаю его успешным, может кому то пригодится такой лайф хак.
select c.id, c.topic from fr_forum_comment c left outer join fr_forum_topic t on c.topic=t.id where t.id is null; id | topic ----------+-------- 16735044 | 330589 16990300 | 343702 (2 rows)
За 10 лет накопилось 2 таких мусорных записи. Это приемлемо.
Так же используем optimistic-lock местами, а местами и select for update, там где требуется повышенная надежность.
В банковском софте, зависит от ситуации. Можно сделать архитектуру что и без FK будет на 100% надежно.
1) Приведенный Вами пример, отличается от того о чем говорю я. Я говорю о ситуации когда, например, в таблицу post параллельно идут по 100 insert/update/delete в секунду. Возникают локи. План их не покажет, а при выполнении запроса он будет выполняться совсем другое время чем в плане предсказано. Я привел немного синтетический пример с форумом, но для того чтобы суть передать. У меня структуры сложнее и одна таблица связана примерно с 20 другими таблицами (это Player с его предметами, ачивками, друзьями и тд и тп), и при удалении юзера из БД начинается вакханалия, если использовать FK, а удалять юзеров приходится огромными массами, потому что иногда случаются DOS атаки на наши игры, и за ночь могут создать несколько миллионов новых юзеров. Понятно, мы защищаемся от атак, но все равно это было много раз.
2) Вижу у Вас в плане seq scan, все таки FK без индексов обычно не используют.
3) Есть такой факт: мы сначала несколько лет разрабатывали с использованием FK, оптимизировали и всё такое, а потом в один день решили дропнуть все FK (они были не cascade, а restrict в основном), дропнули, ничего не поломалось, load avarage на сервере упал с 10-20 до 3-4. То есть при нагрузке FK может жрать не 31%, а примерно 300%-400%.
4) Процессор на сервере норм - 18 ядер, загружен на 15% - 25%. Одно ядро обычно загружается на 100% во время дампа или вакуума, а так все ядра загружены не сильно.
Не, с индексами всё в порядке. Если бы не хватало индексов, то тормозили бы запросы select.
Тормозит такой кейс, например, я удаляю топик на форуме, а в нем 1000 комментов, они тоже должны удалиться. Если каскад обработает БД это будет очень медленно по сравнению с двумя запросами (delete from topics where id=10, и delete from comments where topic_id=10).
Я активно использовал FK пока не начал использвать ORM. На мой взгляд, ORM позволяет жить спойно и без FK.
Ну я тоже многое пилю сам, но типа бут лоадер, ОС, СУБД, IDE , и тп сам не пытаюсь писать, хотя ранее и это пытался. Вот и не пойму в чем у Вас прикол писать именно это, ведь есть тоже удобные надстройки.
Но Вы ответить не можете по существу. Почему 1Мб ок, а 3Мб не ок, вроде был простой вопрос, а в ответ я услышал "я есть там, я есть сям". То что Вас читают ничего не значит. Пескова и Путена тоже миллионы слушают, но верят не все.
По Вашему мнению топовость определят правость? (и кстати, у меня не все статьи и коменты в минус, а коменты в минус так и вообще ничего не значат, их в основном оценивали под эмоциями, как Вы сейчас).
Типа я могу назвать статью "как ходить в туалет" и это оправдает мои подробные описания как я туда сходил? Тут Хабр! как никак, все хотят стать крутыми и богатыми, а не узнать как вы там сходили в то что в теме указали.
В Вашем профиле Хабра я не нашел прямых ссылок на Pikabu и DTF, поэтому сочту Вашу манеру изложения как просто "понты", ну типа "я есть там, я есть сям, поэтому думайте что я крутой", про LibGDX Вы тоже не ответили по существу, почему Вам 1Мб доставляет, а уже аж целых 3Мб противны.
Ну дак а все же ждут рецепт как же заработать мульёны. Кто как пилит свою фигню в гараже, которая не приносит денег, в целом, никому не интересно.
Ну в engine же важно не то, что он просто есть, а то, какое комьюнити, сколько багов исправлено в движке, есть ли поддержка, есть ли перспективы.
Например LibGDX помимо Android может делать сборки для desktop, для webGL, а не так давно мог и для iOS.
Я тоже много что программирую довольно давно, и СУБД свою делал и ОР-маппер, и поисковик для интернет, но это никому не нужно, решение развивается только если есть большое комьюнити. Иначе получается типа "я на asm написал крутую прогу резидентную для DOS зацените пацаны, CRLT-ALT-DEL перехватываю", но это же чисто фан без практической пользы для бизнеса или для комьюнити.
А чем не устраивает, например, LibGDX?
Я его выбираю по тем же соображениям, что чистая Java, и приложение весит, ну не скажу что менее 1Мб, но менее 3Мб.
Как по мне разница между 1Мб и 3Мб не такая большая, как писать работу с OpenGL самому и использовать достаточно мощный инструмент.
Куда то Вас не туда понесло уже. Извините. Удачи.
А зачем тогда это нужно "оценить количество строк при join по FK"? Это число (количество строк) потом как используется? Я понял, что для производительности, чтобы план более оптимальный, например, выбрать. Если я неправильно понял, то поясните зачем это число нужно.
Формально база не консистентна, с этим согласен. Но тут есть важный момент, консистентность ради консистентности нужна разве что студентам, чтобы лабу сдать. Так же как и производительность ради производительности. В моем случае пользователь никогда не узнает об этой неконсистентности, так как вытащить коменты можно только при наличии топика, нет топика, значит нет доступа к комментам удаленного топика. К какой то значимой утечке диского пространства это тоже не приводит.
В рамках моей бизнес логики база "условно консистентна". Это очень удачный компромис между целостностью и производительностью.
А понимаете Вы меня неправильно! Я утверждаю другое.
Если эта информация не Ваш домысел, а из документации Postgres, то скиньте ссылку пожалуйста, просвещусь. Я реально не знаю о том и не понимаю, как наличие FK может ускорить join.
Ну, про индекс написано в плане выполнения запроса, если он есть то будет index scan и будет быстро, если его нет будет seq scan и будет медленно. А вот наличие или отсутствие FK ни как не влияет на быстро/медленно. Или я не прав?
Но чтобы эту "только одну" быстро найти нужен именно индекс, а не FK. В этом можно убедиться если посмотреть план выполнения запроса, что используется именно индекс, а не FK. Или нет?
А в какой СУБД, например, это есть?
Мне просто сам принцип непонятен, как FK может помочь при джойне. Я понимаю индексы - это да, я понимаю что в СУБД индексы могут автоматически создаваться при создании FK, но чтобы FK без индекса как-то помогал такого не знаю.
За что минусуют не пойму. Я же не топлю за то что FK - это однозначное зло. С академической точки зрения FK вещь красивая и полезная, но когда разработчикам надо больше производительности приходится чем то жертвовать, так и появляются всякие NoSQL, дроп констрейнтов и т.п. Я просто делюсь своим опытом, и считаю его успешным, может кому то пригодится такой лайф хак.
select c.id, c.topic from fr_forum_comment c left outer join fr_forum_topic t on c.topic=t.id where t.id is null;id | topic
----------+--------
16735044 | 330589
16990300 | 343702
(2 rows)
За 10 лет накопилось 2 таких мусорных записи. Это приемлемо.
Так же используем optimistic-lock местами, а местами и select for update, там где требуется повышенная надежность.
В банковском софте, зависит от ситуации. Можно сделать архитектуру что и без FK будет на 100% надежно.
1) Приведенный Вами пример, отличается от того о чем говорю я. Я говорю о ситуации когда, например, в таблицу post параллельно идут по 100 insert/update/delete в секунду. Возникают локи. План их не покажет, а при выполнении запроса он будет выполняться совсем другое время чем в плане предсказано. Я привел немного синтетический пример с форумом, но для того чтобы суть передать. У меня структуры сложнее и одна таблица связана примерно с 20 другими таблицами (это Player с его предметами, ачивками, друзьями и тд и тп), и при удалении юзера из БД начинается вакханалия, если использовать FK, а удалять юзеров приходится огромными массами, потому что иногда случаются DOS атаки на наши игры, и за ночь могут создать несколько миллионов новых юзеров. Понятно, мы защищаемся от атак, но все равно это было много раз.
2) Вижу у Вас в плане seq scan, все таки FK без индексов обычно не используют.
3) Есть такой факт: мы сначала несколько лет разрабатывали с использованием FK, оптимизировали и всё такое, а потом в один день решили дропнуть все FK (они были не cascade, а restrict в основном), дропнули, ничего не поломалось, load avarage на сервере упал с 10-20 до 3-4. То есть при нагрузке FK может жрать не 31%, а примерно 300%-400%.
4) Процессор на сервере норм - 18 ядер, загружен на 15% - 25%. Одно ядро обычно загружается на 100% во время дампа или вакуума, а так все ядра загружены не сильно.
Не, с индексами всё в порядке. Если бы не хватало индексов, то тормозили бы запросы select.
Тормозит такой кейс, например, я удаляю топик на форуме, а в нем 1000 комментов, они тоже должны удалиться. Если каскад обработает БД это будет очень медленно по сравнению с двумя запросами (delete from topics where id=10, и delete from comments where topic_id=10).
Я активно использовал FK пока не начал использвать ORM. На мой взгляд, ORM позволяет жить спойно и без FK.
можно узнать откуда эта инфа?