BG Development


Страници: (5) 1 2 [3] 4 5   ( Първото ново мнение ) Reply to this topicStart new topicStart Poll

> Структуриране на БД
thrawn
Публикувано на: 12-12-2018, 16:06
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2709
Регистриран на: 17.01.17



QUOTE (Gamma Goblin @ 12-12-2018, 16:03)
QUOTE (thrawn @ 12-12-2018, 16:00)
Оптимизацията си е заложена от авторите на базата данни - count(*) например.

https://wiki.postgresql.org/wiki/Slow_Counting

броенето е бавно

Броенето обикновено е по индекс...
PMEmail Poster
Top
Gamma Goblin
Публикувано на: 12-12-2018, 16:31
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 3394
Регистриран на: 21.02.18



QUOTE (thrawn @ 12-12-2018, 16:06)
QUOTE (Gamma Goblin @ 12-12-2018, 16:03)
QUOTE (thrawn @ 12-12-2018, 16:00)
Оптимизацията си е заложена от авторите на базата данни - count(*) например.

https://wiki.postgresql.org/wiki/Slow_Counting

броенето е бавно

Броенето обикновено е по индекс...

хората са написали цяло уики дето ти казват че е бавно ти пак индекс та индекс.


--------------------
https://www.rust-lang.org/
---
https://ncase.me/trust-bg/
---
Misanthropy is the general hatred, dislike, distrust or contempt of the human species or human nature. A misanthrope or misanthropist is someone who holds such views or feelings.
---
INTJ’s are good at being very good at everything
---
PMEmail PosterUsers Website
Top
thrawn
Публикувано на: 12-12-2018, 16:35
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2709
Регистриран на: 17.01.17



Ми прочети края бе човек - там ти пише, че АКО ползваш индекс това ще подобри нещата. Дори ти пише, че това е специфика на postgresql и че други бази данни ще ти изплюят директно резултат на база индекси без да проверяват дали записите отговарят.

И пак ти казвам, проблемът е в това, че не можеш да направиш брояч без да заключваш таблиците. Не случайно в postgresql броячите не са транзакционни обекти.
PMEmail Poster
Top
Golden Gega
Публикувано на: 12-12-2018, 16:39
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1761
Регистриран на: 04.06.10



Едно "най-удачно" няма, зависи от приоритетите:

1) Ако базата е малка и натоварването слабо, най-добре е да се брои с count - най-малко време за изпълнение и после за поддръжка
2) Ако базата е е голяма и натоварването голямо, тогава е добре да има брояч. И тук навлизаме в някои случаи (ако базата е релационна и не се ползва кеш):
2.1) Ако се гони топ пърформанс е добре броячите да са отделно - така при update се заключва само таблицата с броячите, не с основните данни и това ускорява работата с тези данни
2.2) Ако се гони относителен пърформанс брояча може да е на основната таблица за по-проста схема на базата
2.3) По отношение на това как да се реализира брояча - с тригер или от DAL с транзакция - добре е да се следва основния начин на работа. Имал съм случай за голяма система където всичко беше с ORM/DAL, и единична операция беше с тригер - сума ти време се загуби при дебъгване да се установи че има наличен тригер и заради него нещо не излиза.

В конкретния случай, както казаха и по-горе, натоварването е насочено към четенето, предполага се че това ще кисне на общ хостинг - демек желязото ще е кът, съответно най-оптималния като труд и натоварване вариант е брояч в основната таблица и промяната му в DAL-а с транзакция, дори само затова кода да е на едно място и да не се забравя кое къде се променя.
PMEmail Poster
Top
thrawn
Публикувано на: 12-12-2018, 16:46
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2709
Регистриран на: 17.01.17



То реално не зависи от размера на базата данни а от броя на данните които ще се броят. Може да имаш база данни с милярди записи, но да искаш да броиш малки блокове (каквито са коментарите). Демек, след като филтрираш по индекс остават няколко десетки (да кажем 200 записа). Е колкото и "бавно" да е count(*) на 200 записа то не си струва разправията с отделни броячи.
PMEmail Poster
Top
johnfound
Публикувано на: 12-12-2018, 16:48
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 7763
Регистриран на: 27.05.04



QUOTE (thrawn @ 12-12-2018, 17:35)
И пак ти казвам, проблемът е в това, че не можеш да направиш брояч без да заключваш таблиците. Не случайно в postgresql броячите не са транзакционни обекти.

Е-е-е, аз ли не разбирам за какво точно говорим? Аз специално говоря за брояч като поле в таблица, което се обновява при запис/изтриване/промени в друга таблица.

По принцип, ако се направи с тригери, няма да има проблем нито транзакциите нито с конкурентността. Поне в тези бази данни, които аз познавам.

Ето един пример от мой проект в който се ъпдейтват едновременно няколко брояча:

CODE

CREATE TRIGGER PostsAI AFTER INSERT ON Posts BEGIN
 update Users set PostCount = PostCount + 1 where Users.id = new.UserID;
 update Threads set PostCount = PostCount + 1 where id = new.threadID;
END;

CREATE TRIGGER PostsAD AFTER DELETE ON Posts BEGIN
 update Users set PostCount = PostCount - 1 where Users.id = old.UserID;
 update Threads set PostCount = PostCount - 1 where id = old.threadID;
END;

CREATE TRIGGER PostsAU AFTER UPDATE OF Content, editTime, editUserID, threadID, format ON Posts BEGIN
 update Threads set PostCount = PostCount - 1 where id = old.threadID;
 update Threads set PostCount = PostCount + 1 where id = new.threadID;
END;


Разбира се, както казах, това си е сериозен компромис от архитектурна гледна точка, но не виждам откъде могат да дойдат проблеми с конкурентността.


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
PMEmail PosterUsers Website
Top
Golden Gega
Публикувано на: 12-12-2018, 16:54
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1761
Регистриран на: 04.06.10



То реално като се каже голяма база хората в бранша разбират много записи а не много гиги.
Какво струва вече е въпрос на преценка и баланс.
PMEmail Poster
Top
johnfound
Публикувано на: 12-12-2018, 16:58
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 7763
Регистриран на: 27.05.04



QUOTE (thrawn @ 12-12-2018, 17:46)
Демек, след като филтрираш по индекс остават няколко десетки (да кажем 200 записа). Е колкото и "бавно" да е count(*) на 200 записа то не си струва разправията с отделни броячи.

На пръв поглед си прав. Само че, има едно но – зависи колко често ти трябват тези бройки. Ако се налага да правиш десетки такива заявки, то нещата бързо излизат извън контрол.

В AsmBB аз имам на рендирана страница примерно по 3 брояча на тема и 20 теми на страница - брой на потребителите, брой на постовете в темата, брой на непрочетените постове, колко хора са прочели темата (а тука вече сме далеч повече от бройката 200 - по-скоро 20000).

Първоначално го бях направил именно с броене всеки път. Но производителността деградираше наистина бързо при нарастване на базата данни. Това при всички необходими индекси дефинирани и всяка заявка ръчно оптимизирана с "explain".

Така че накрая се наложи да се правят броячи и много тригери.

Това мнение е било редактирано от johnfound на 12-12-2018, 16:59


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
PMEmail PosterUsers Website
Top
wqw
Публикувано на: 12-12-2018, 17:05
Quote Post


Group Icon
Име: Владимир Висулчев
Група: VIP
Ранг: Почетен член

Мнения: 6174
Регистриран на: 10.06.04



QUOTE (johnfound @ 12-12-2018, 16:58)
Но производителността деградираше наистина бързо при нарастване на базата данни. Това при всички необходими индекси дефинирани и всяка заявка ръчно оптимизирана с "explain".

Забрави най-важната подробност -- заявките ги мяташ към sqlite. При нормална RDBMS щеше да деградира по-бавно.

cheers,
</wqw>


--------------------
PMEmail PosterUsers Website
Top
thrawn
Публикувано на: 12-12-2018, 17:05
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2709
Регистриран на: 17.01.17



Точно с кокурентността има проблем. Нали ъодейтваш един и същи ред. Освен това, не забравяй, че има и rollback
PMEmail Poster
Top
0 потребители преглеждат тази тема в момента (0 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Страници: (5) 1 2 [3] 4 5  Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2019 | BG Development | All Rights Reserved
RSS 2.0