BG Development


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

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



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

Мнения: 2490
Регистриран на: 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



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

Мнения: 2780
Регистриран на: 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/
---
Хора, които са прекалено умни, за да се занимават с политика, са наказани да бъдат управлявани от глупаци.
---
Life is hard; it's harder when you're stupid.
---
Black metal is like coffee. You have to learn to drink it but when you get used to it, you just want it darker and darker
PMEmail PosterUsers Website
Top
thrawn
Публикувано на: 12-12-2018, 16:35
Quote Post



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

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



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

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



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

Мнения: 1624
Регистриран на: 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



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

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



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


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

Мнения: 7634
Регистриран на: 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



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

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



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


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

Мнения: 7634
Регистриран на: 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
Ранг: Почетен член

Мнения: 6110
Регистриран на: 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



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

Мнения: 2490
Регистриран на: 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