Jarosław Zabiełło - BLOG: Tag mysql

PostgreSQL vs MySQL vs MSSQL2K

Jarosław Zabiełło — Mon, 02 Apr 2007 17:14:00 +0200

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.

Użyto następującego kodu w Pythonie:

import adodbapi, MySQLdb, odbc, psycopg2, time
conn = [
  ( 'mysql', MySQLdb.connect(user='root', db='test'), 'SHOW TABLES'),
  ('pgsql', psycopg2.connect("user='postgres' password='test''"), 'SELECT * FROM pg_tables jdb273'),
  ('mssql ado', adodbapi.connect('Provider=SQLNCLI.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=test'), 'EXEC sp_tables'),
  ('mssql odbc', odbc.odbc('DRIVER={SQL Server};SERVER=localhost;DATABASE=test;UID=sa;PWD=test'), 'EXEC sp_tables'),
  ]
def test(repeat=100):
  for c in conn:
    dbtype, db, sql = c
    print dbtype,
    t = time.time()
    for i in range(repeat):
      cursor = db.cursor()
      cursor.execute(sql)
      rows = cursor.fetchall()
      cursor.close()
    print '%d req/s' % round(repeat / (time.time() - t))
if __name__ == '__main__':
  test()

Użyta konfiguracja:

WinXP Pro 2000 SP2, P4 3.2GHz, 1GB RAM.
Python 2.5
MySQL v5.0. 27, driver: MySQLdb v1.2.2
PostgreSQL v8.2.3, driver: psycopg2 v2.0.6b1 (dec dt ext pq3)
MSSQL 2000 SP4, driver: ADO

Wyniki:

C:\home\app\bench\scripts>bench_db.py
mysql 457 req/s
pgsql 581 req/s
mssql ado 6 req/s
mssql odbc 9 req/s

C:\home\app\bench\scripts>bench_db.py
mysql 457 req/s
pgsql 581 req/s
mssql ado 9 req/s
mssql odbc 10 req/s

C:\home\app\bench\scripts>bench_db.py
mysql 457 req/s
pgsql 578 req/s
mssql ado 9 req/s
mssql odbc 11 req/s

C:\home\app\bench\scripts>bench_db.py
mysql 457 req/s
pgsql 581 req/s
mssql ado 8 req/s
mssql odbc 11 req/s

C:\home\app\bench\scripts>bench_db.py
mysql 455 req/s
pgsql 641 req/s
mssql ado 9 req/s
mssql odbc 10 req/s

Mit o rzekomej szybkości MySQL już jest nieaktualny. Nowy PostgreSQL 8 bije go pod każdym względem. Zarówno wydajnościowo i jak i znacznie większymi mozliwościami (o tym może kiedy indziej). Dziwi słaba, a raczej nędzna, wydajność produktu firmy Microsoft. Nie sprawdzałem nowego MSSQL 2005, ale wszystko wskazuje na to, że przynajmniej MSSQL2K to kompletne dno!

MySQLdb i problem polskich znaków

Jarosław Zabiełło — Fri, 16 Mar 2007 02:36:00 +0100

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.

W wypadku wersji edge (z SVN), należy dodać:

DATABASE_OPTIONS = {'use_unicode': True, 'charset': 'utf8'}

W przypadku starszego kodu to nie pomagało. Musiałem wyłączyć zwracanie wyników w postaci obiektów unikodowych Pythona. W tym wypadku podziałała opcja:

DATABASE_OPTIONS = {'use_unicode': False, 'charset': 'utf8'}

Widzę, że Django najwyraźniej idzie w tym samym kierunku co Pylons, tzn. myśli aby wszystkie stringi i pracę z bazą oprzeć na obiektach unikodowych a nie stringach UTF-8. W wypadku Pylonsów, ich najnowszy system szablonów Mako standardowo już pracuje wewnętrznie na czystych obiektach unikodowych Pythona.

Uwaga! Django ma trochę niedopracowanego kodu. Np. panel admina się sypie jak ustawiona jest powyższa opcja z włączonym unikodem. Trzeba ją wyłączyć. Ale wtedy z kolei źle się wyświetla część tekstów zawierająca polskie znaki (np. imię czy nazwisko redaktora). Jednak lepsza to niż w ogóle brak możliwości edycji rekordów. Wniosek: dla Django używaj drugiej opcji. Aktualnie kod Django jeszcze nie dorósł do tego, aby używać pełnego unikodu z bazą MySQL.

Głupie zachowanie MySQL

Jarosław Zabiełło — Sun, 31 Dec 2006 05:16:00 +0100

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.

MySQLdb & client encoding

Jarosław Zabiełło — Wed, 16 Aug 2006 01:28:00 +0200

[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')

MySQL 5 - strzeż się się tego koszmaru

Jarosław Zabiełło — Mon, 29 May 2006 09:54:00 +0200

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!”