PostgreSQL vs MySQL vs MSSQL2K

Opublikowane przez Jarosław Zabiełło Mon, 02 Apr 2007 15:14:00 GMT

Zawsze dziwiłem się dlaczego aplikacje komunikujące się z MSSQL chodzą tak niemrawo. Zrobiłem sobie szybki test szybkości. Na tym samym komputerze zainstalowałem: MSSQL 2000 SP4, MySQL 5.0.27 i PostgreSQL 8.2.3. Zadanie było proste, pobrać listę tabel w bazie.

Czytaj dalej...

Tagi , , ,  | 45 comments

MySQLdb i problem polskich znaków

Opublikowane przez Jarosław Zabiełło Fri, 16 Mar 2007 01:36:00 GMT

W końcu pojawiła się wersja stabilna pythonowej biblioteki MySQLdb 1.2.2. Co ciekawsze, jest dostępna instalacja w formie pakieru egg zarówno dla Pythona 2.4 jak i 2.5. Nie trzeba też już więcej używać instalatorów binarnych pod windozą. Wystarczy (zakładając że mamy zainstalowane setuptoolsy) wykonać komendę:

easy_install -U MySQL_python

Osoby używające Django i MySQL5 muszą pamiętać aby dodać dodatkową opcję do settings.py.

Czytaj dalej...

Tagi , ,  | 5 comments

Głupie zachowanie MySQL

Opublikowane przez Jarosław Zabiełło Sun, 31 Dec 2006 04:16:00 GMT

Jak ktoś chce się pośmiać z MySQL, to niech zajrzy tutaj. Sprawdzałem nawet na najnowszym stabilnym MySQL 5.0.27. Czasem można dodać rekord o tym samym kluczu głównym, a czasem nie można. Po prostu obciach.

Tagi  | 10 comments

MySQLdb & client encoding

Opublikowane przez Jarosław Zabiełło Tue, 15 Aug 2006 23:28:00 GMT

[vide: English version]

MySQLdb to główna biblioteka dla Pythona obsługująca bazę MySQL. Baza ta (od werseji 4.1 wzwyż) ma wbudowany wygodny mechanizm translacji znaków jakie mają być wyświetlane dla klienta. Oczywiście, należy założyć, że natywnym formatem danych dla bazy to UTF-8. Za pomocą prostej kwerendy (SET NAMES latin2) można wymusić aby wszelkie napisy były wypluwane do klienta w wybranym formacie (tu: iso-8859-2).

Ostatnio, przy okazji pracy z Pylons, przyjrzałem się bardzo ciekawemu projektowi: SQLAlchemy. Wszystko wskazuje na to, że SQLObject odejdzie do lamusa (tym bardziej że jego twórca coś go porzucił i planuje stworzyć nowy SQLObject2). SQLAlchemy jest nie tylko znacznie poteżniejszym ORM, ale ma także znacznie lepszą dokumentację niż SQLObject – ok. 117 stron samego tylko manuala.

Jedyny problem, jakie to typowe, to brak czytelnej opcji translacji polskich znaków. Podobny problem swego czasu znalazłem w Django (wysłałem patcha i to poprawili dodając na sztywno “SET NAMES utf8”) W wypadku SQLAlchemy nie ma opcji do definicji kodowania po stronie klienta. Manual wspomina tylko o ustawieniu kodowania dla bazy, a to nie to samo. Okazuje, się, że rozwiązanie jest bardzo proste. Podczas tworzenia połączenia do bazy wystarczy użyć dodatkowych parametrów. Nie ma potrzeby bawienia się w żadne kwerendy “SET NAMES”. Owe parametry to use_unicode i charset:

import MySQLdb
conn = MySQLdb.connect(
    user='root', 
    passwd='', 
    db='test', 
    use_unicode=False, 
    charset='cp1250')

W powyższym wypadku, MySQL będzie zakładał że klient ma odebrać teksty w formacie stringów cp1250. Zaś w wypadku użycia “use_unicode=True” zwracane będą śliczne obiekty unicodowe! Przykładowy plik konfiguracyjny dla Pylonsa korzystającego z SQLAlchemy (config/init.py) może zatem wyglądać np. tak:

from sqlalchemy import *
import sqlalchemy.pool as pool
import MySQLdb

def getconn():
    return MySQLdb.connect(
        user='root', 
        passwd='', 
        db='test', 
        use_unicode=False, 
        charset='utf8')

db = create_engine(
    'mysql://root:@localhost/test',
    pool=pool.QueuePool(getconn, pool_size=20, max_overflow=40), 
    strategy='threadlocal')
metadata = BoundMetaData(db)

test_table = Table('test', metadata, autoload=True)

class Test(object):  
    def __str__(self):  
        return self.title  

test_mapper = mapper(Test, test_table) 

W powyższym przykładzie, wymusiłem kodowanie utf8 dla klienta oraz połączenie z bazą działać będzie w puli 20-40 wątków. Właśnie tego mi brakuje w Django: pracy wielowątkowej, bo zużywa ona mniej pamięci. W/w model można użyć w kontrolerze Pylons (controllers/home.py) np. tak:

from myproject.lib.base import *
from myproject.models import *

class HomeController(BaseController):
  def index(self):        
      c.rows = select([test_table.c.id, test_table.c.name]).execute()
      return render_response('/home.myt')

Posted in , ,  | Tagi , , ,  | 4 comments

MySQL 5 - strzeż się się tego koszmaru

Opublikowane przez Jarosław Zabiełło Mon, 29 May 2006 07:54:00 GMT

Baza MySQL nigdy nie uchodziła za wzór poprawnej pracy, ale to co ostatnio się z nią dzieje woła o pomstę do nieba… Zainstalowałem sobie najnowszą wersję stabilną MySQL 5 pod win32. Wpierw myslałem że znalazłem jakiś błąd we frameworku Django. Ale krótki czat z innymi programistami i przejrzenie netu, pozbawił mnie złudzeń. Błąd leży w silniku samej bazy. Włączyłem logowanie zapytań i uruchomiłem kwerendę bezpośrednio z poziomu klienta.

Otóż okazuje się, że w MySQL5 kompletnie popsuta jest obsługa warunku “LIKE”. Ilość zwracanych rekordów jest większa niż być powinna. I to nie chyba ma nic wspólnego z tym, czy kodowanie tabel jest w UTF8 czy nie, gdyż nadmierna ilość rekordów jest znajdowana nawet, jak wyszukuje się słowo zawiera tylko znaki ASCII.

Inne “kwiatki” związane z MySQL, o których trzeba sobie jasno powiedzieć, to notoryczne niszczenie plików indeksowych w wypadku zbyt dużego obciążenia bazy. Oczywiście to można łatwo naprawić za pomocą kwerendy REPAIR TABLE tabelka. Ale dopóki nie wykona się tej operacja, tabela nie jest dostępna i aplikacja nam się wywali. Tego typu problemy zauważyłem na MySQL 4.x i 4.1. Nie miałem okazji poddać większym obciążeniom bazę MySQL 5.x, ale nie zdziwiłbym się jakby też z nią były problemy.

Zawsze tyle się mówi w branży, że MySQL to niepoważny projekt amatorski (słaba stabilność i niszczenie swoich tabel pod dużym obciążeniem, koszmarnie wolne tabele transakcyjne innodb, słaba obsługa lockowania – tylko na poziomie tabel a nie wierszy itp, itd) Niszczenie swoich tabel indeksowych mogłem jeszcze zdzierżyć, ale błędna obsługa wyszukiwania tak podstawowej operacji jak LIKE? No way. Całe szczęście, że Django ma dobry ORM i można łatwo zmigrować do PostgreSQL. Chyba nie ma innego wyboru jak powiedzieć: “Goodbye MySQL and welcome PostgreSQL!”

Zobacz c.d. MySQL5 rehabilitacja

Posted in  | Tagi  | 13 comments