Wpisy z tagiem: postgresql
Tagi popularne na mikroblogu
- programowanie × 853
- off-topic × 560
- autopromocja × 392
- links × 235
- 4programmers.net × 233
- koziolekweb × 230
- blog × 188
- coyote × 173
- praca × 173
- lazarus × 151
Oracle 
MySQL 
PostgreSQL 
SQL Gdzie powinny być przechowywane pliki binarne użytkowników twojej aplikacji ? W systemie operacyjnym czy bazie danych ?
Jeśli użytkownicy twojej aplikacji mają przechowywać pliki - np. dokumenty w formacie pdf lub skany, zdjęcia, dźwięki czy filmy - to gdzie najlepiej będzie je magazynować ? Czy będzie to baza danych z możliwością przechowywania BLOB'ów ? Czy raczej katalog w systemie operacyjnym, a w bazie danych będzie przechowywana jedynie ścieżka do pliku i metadane ? Co decyduje o wyborze jednego z tych rozwiązań ?
Gdy powstawały relacyjne bazy danych u ich podstaw legła potrzeba przechowywania dużej ilości danych w małych porcjach i w określonym porządku. Podczas gdy systemy plików zostały zaprojektowane do przechowywania danych w dużych porcjach i bez określonego porządku. Gdzie obecnie leży granica wielkości pliku, za którą baza danych lub system plików będzie lepszym rozwiązaniem ?
Oto lista czynników wartych rozważenia:
- łatwość implementacji - jakimi kompetencjami i narzędziami dysponuje zespół tworzący aplikację
- prostota zarządzania i defragmentacji - jak często i jakim kosztem można przenosić i defragmentować dane
- wydajność - które z rozwiązań pozwala na wydajniejszy zapis/modyfikację i odczyt danych. Czy pozwala na modyfikację fragmentu pliku/BLOB'a czy zawsze nadpisuje całość ?
- synchronizacja - jakie rozwiązanie trzeba zastosować aby mieć spójny bekap i możliwość odtworzenia plików/BLOB'ów zsynchronizowanych z metadanymi
- bezpieczeństwo - inny system przywilejów w systemie operacyjnym i bazie danych
- transakcyjność - zapis pliku w bazie danych jest fragmentem transakcji natomiast zapis w systemie operacyjnym nie jest transakcją
- pliki w bazie danych są bezpieczne przed wirusami - są zapisane w wewnętrznych strukturach bazy danych bez bezpośredniego dostępu dla innych procesów systemu operacyjnego
- dzielenie ogromnych plików (np. wideo) na mniejsze, łatwiejsze w zarządzaniu kawałki
- scalanie dużej ilości maleńkich plików w archiwa, np. TAR lub ZIP
- odporność na uszkodzenia, np. pad systemu - większość systemów plików zabepiecza jedynie swoje wewnętrzne struktury, a nie zawartość plików podczas gdy baza danych skupia się na zabezpieczeniu danych
- zapis danych - systemy plików i systemy operacyjne dostosowują kolejność zapisu bloków pliku aby zwiększyć wydajność - nie zapisują sekwencyjnie. Natomiast baza danych grupuje zmiany w blokach aby zapisywać ich większe porcje razem - zapisuje sekwencyjnie.
- replikacja - jak spójnie replikować system plików i metadane z bazy danych, np. na potrzeby wysokiej dostępności lub do systemu testowego ?
- skalowalność - setki tysięcy, miliony czy nawet miliardy rekordów w pojedynczej tabeli (szczególnie spartycjonowanej) nie są wyzwaniem dla bazy danych, podczas gdy dziesiątki tysięcy plików w systemie plików są trudne do obsłużenia dla systemu operacyjnego
- audyt - bazy danych mają wbudowane narzędzia do audytu - kiedy i w jaki sposób uzyskano dostęp do konkretnego BLOB'a
A może trzecia opcja: trzymanie najczęściej wykorzytywanych BLOB'ów w systemie operacyjnym jako pliki + ich wzorzec w bazie danych, jest najbardziej optymalna ?
#oracle #database #mysql #postgresql #sqlserver #sql #BLOB #dba4dev #marcinbadtke
@several: Dzięki za komentarz :-) Wpis miał inspirować, a nie ewangelizować ;-)
Masz 10 minut?
W 10 minut poznasz mechanizmy powstawania DEADlock'ów - zakleszczeń. Sposoby baz danych na ich rozwiązywanie. Oraz jak zminimalizować ryzyko występowania DEADlock'ów. Przy okazji będzie trochę o lock'ach i transakcjach.
- lekko spóźniony materiał Halloween'owy.
#database #oracle #mysql #postgresql #sqlserver #sql #dba4dev #marcinbadtke
Ciekawostka dotycząca postgresql:
Przygotowałem mały quiz:
http://sqlfiddle.com/#!17/5cf1c/7
pytanie co zwróci zapytanie
select * from testa where txt is null
Tak więc uważajcie na stosowanie concat(null,null) ;)
#postgresql, #concat
@Shalom: znam dokumentację czytałem dlatego zostawiłem przykład aby każdy mógł się przekonać sam co ten zapis tak na prawdę znaczy :D
MongoDB 
Cassandra W nowym projekcie potrzebuje bazy która dobrze będzie sobie radziła z szybkością zapisu danych. Większość operacji to będzie INSERT lub UPDATE. Postanowiłem napisać prosty skrypt do benchmarku w Pythonie. Sprawdziłem PostgreSQL 12, MongoDB 4 oraz Cassandara 3. Wszystkie bazy w kontenerze dockerowym, jedna instancja oraz domyślna konfiguracja.
Prawdopodobnie chcąc uzyskać bardziej realne wyniki powinienem taki benchmark napisać w bashu, gdyż może być jakieś wąskie gardło w bibliotece/sterowniku do bazy, ale napisałem w Pythonie ponieważ cały projekt będzie w tym języku.
Test nr 1. Dodanie 1 mln rekordów do pustej tabeli/kolekcji z dwoma kolumnami (w tym primary key)
PostgreSQL: 1:02 min.
MongoDB: 5:04 min.
Cassandra: 6:37 min.
Test nr 2. Dodanie 1 mln rekordów do tabeli/kolekcji zawierającej 1 mln wierszy
Czasy podobne jak w przypadku dodanie do pustej.
Test nr 3. Dodanie 1 mln rekordów do tabeli/kolekcjami z 2 indeksami
PostgreSQL: 1:11 min.
MongoDB: 5:16 min.
Cassandra: 7:32 min.
Test nr 4. Update 1 mln rekordów
PostgreSQL: 16 sek
MongoDB: 20 sek
Cassandara: brak informacji (nie potrafię tego zrobić)
Zastanawia słaby czas Cassandry (być może wymaga jakiejś dodatkowej konfiguracji albo pokazuje swe pazury dopiero przy kilku nodach) oraz zaskakuje nadzwyczaj dobry czas PostgreSQL.
#postgresql #mongodb #cassandra
@Krolik: bardzo możliwe ponieważ nie znam cassandry. Skrypcik był bardzo prosty, coś w stym stylu:
from cassandra.cluster import Cluster
from datetime import datetime
import random
cluster = Cluster(['cassandra'])
session = cluster.connect('test')
session.execute("CREATE TABLE test (id int, x int, y int, PRIMARY KEY(id));")
session.execute("CREATE INDEX test_x ON test (x)")
for i in range(1000000):
session.execute('insert into test (id, x, y) values(%d, %d, %d)' % (i, random.randint(0, 100000), random.randint(0, 100000)))
No tak, to zrobiłeś to sekwencyjnie, blokująco i bez prepared statements. Zamień chociaż na executeAsync.
Docker W pewnym projekcie, gdzie używamy bazy danych PostgreSQL w Dockerze do celów testowo-developerskich, potrzebowaliśmy tworzyć joby, które będą wykonywać się co określony interwał czasowy. Problem w tym, że PostgreSQL domyślnie nie posiada takiego mechanizmu, który by na to pozwalał.
Do wyboru mamy dwa pluginy: pg_cron oraz pgAgent.
Początkowo naturalnym wydawał się pg_cron, jednak po zagłębieniu się w jego specyfikację, okazało się, że wymaga on podania na sztywno w pliku konfiguracyjnym nazwy bazy danych.
Niestety nie sprostało to naszym wymaganiom, ponieważ w obecnym projekcie tworzymy dynamicznie bazy danych i na etapie konfiguracji nawet nie znamy ich nazw.
Zobacz jak sobie z tym poradziłem :)
https://szkoladockera.pl/jak-uruchomic-jednoczesnie-dwa-procesy-w-kontenerze-przyklad-z-zycia/
#docker #postgres #kontener #czwartkizdockerem
Java Z okazji chorobowego macie tutaj kilka słów o ciekawym „problemie” z jakim ostatnio się spotkałem https://koziolekweb.pl/2020/02/04/o-stringow-w-postgresie-porownywaniu/
#java #koziolekweb #postgres
Taka ciekawostka na temat lower i upper -> są unicodowe znaki dla których upper i lower nie są symetryczne ;] Znak stopni Kelvina to taki przykład :)
"K".toUpperCase() == "K" // false
"K".toLowerCase() == "k" // true
Dlatego ja bym mocno uważał z takimi lowercase/uppercase konwersjami, bo można się mocno zdziwić.
@cerrato - to co usuwasz w funkcji zależy od zastosowania. Podałem przykład dla nazwiska bo takiego rozwiązania używałem. Faktycznie dla emaila znaku @ nie powinno się usuwać. Kropek po @ też raczej nie, bo mogą zmienić nazwę domeny.
@several: nie marudź już. Bardzo fajny wpis