set nocount on;Тогда данные получаются нормально.
четверг, 17 декабря 2009 г.
SQLAlchemy + MSSQL + Stored Procedure | Решение проблемы получения данных из хранимых процедур
Нашел решение. Нужно в скрипте хранимки вставить
пятница, 4 декабря 2009 г.
Werkzeug + SQLAlchemy + Jinja2 + Memcached = Маст трай
Да, да, да! Дошли таки руки! Django отложен в темный ящик, так как мне нужна бОльшая гибкость. Да и админка не нужна совсем в том проекте, который делаю (секрет :-).
Хорошо, что перед встречей с werkzeug я поковырялся с GAE Python (сделал нечто вроде блога). Это помогло мне сделать этакий фреймворк для обработки запросов.
К примеру сделал свой базовый класс Controller. Это объект с response и request классами внутри.
Куски класса:
Еще очень обрадовал шаблонизатор:
- он кэширует шаблоны! (т.е. хранит их в своем пре-компилед виде).
- макросы (можно загружать из файла)
Отдельно помучался с апачем + wsgi. Но как обычно - документация спасает.
П.С.: просто надоел зависающий IIS6
Хорошо, что перед встречей с werkzeug я поковырялся с GAE Python (сделал нечто вроде блога). Это помогло мне сделать этакий фреймворк для обработки запросов.
К примеру сделал свой базовый класс Controller. Это объект с response и request классами внутри.
Куски класса:
class Controller():
def __init__(self, request):
def get(self): #вызывается при get-запросе
def post(self): #вызывается при post-запросе
def render_template(self, template, **context): #так вызывается шаблонизатор
def preprocess(self): # дергается в конце инициализации. сюда можно навесить декоратор для проверки прав доступа
Кроме того, Controller при каждой инициализации создает в себе объект self.current_user - думаю понятно что это :-)Еще очень обрадовал шаблонизатор:
- он кэширует шаблоны! (т.е. хранит их в своем пре-компилед виде).
- макросы (можно загружать из файла)
Отдельно помучался с апачем + wsgi. Но как обычно - документация спасает.
П.С.: просто надоел зависающий IIS6
воскресенье, 8 ноября 2009 г.
Cherokee + uWSGI + Django How-To
Навеяно:
http://habrahabr.ru/blogs/python/67475/
http://m.habrahabr.ru/post/70531/
---
Решил тут я попробывать веб-сервер cherokee для django-сайта. Обычно используется flup-прослойка, а я хотел задействовать uwsgi.
Что я сделал (опишу успешные шаги):
1. создал новый django-проект
2. создал новый app "dummy" с простым выводом:
4. сайты у меня находятся в каталоге /var/www-cherokee (владелец www-data)
5. в каталог django1 я скопировал свой проект.
6. в /var/www-cherokee нужно поместить uwsgi.xml - это конфигурационный файл для запуска джанго-сайта. содержание моего:
7. в /var/www-cherokee/django1 помещаем скрипт для вызова джанго (django_wsgi):
так же в параметре "Interpreter" проверьте путь до конфига uwsgi.xml (у меня строка выглядит так: /usr/bin/uwsgi -s /tmp/cherokee-source11.sock -C -x /var/www-cherokee/uwsgi.xml )
В принципе - все. Перезапустил сервер и в браузере увидел "hello..."
П.С.: о сломанных копьях в процессе конфигурации я умолчу. если что - я настраивал по этому посту.
П.П.С: если что то не работает (я сначала получал только "uwsgi error" в браузере) - попробуйте запустить в окне терминала строчку из настройки интерпретатора (/usr/bin/uwsgi -s /tmp/cherokee-source11.sock -C -x /var/www-cherokee/uwsgi.xml) и не закрывая его обновить страницу в браузере. потом в терминале можно увидеть ошибки (я так нашел неправильно указанный путь)... ВНИМАНИЕ! после запуска интерпретатора в ручную нужно удалять файл /tmp/cherokee-source11.sock (в моем случае)!
---
тесты:
1. flup
2. uWSGI
= 1 =============
Document Length: 18 bytes
Concurrency Level: 10
Time taken for tests: 102.068 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 1660166 bytes
HTML transferred: 180018 bytes
Requests per second: 97.97 [#/sec] (mean)
Time per request: 102.068 [ms] (mean)
Time per request: 10.207 [ms] (mean, across all concurrent requests)
Transfer rate: 15.88 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 1.8 0 39
Processing: 3 101 241.3 39 3777
Waiting: 0 98 236.6 38 3777
Total: 3 102 241.3 40 3778
Percentage of the requests served within a certain time (ms)
50% 40
66% 56
75% 69
80% 79
90% 171
95% 292
98% 1125
99% 1226
100% 3778 (longest request)
= 2 =============
Document Length: 18 bytes
Concurrency Level: 10
Time taken for tests: 20.044 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 1660000 bytes
HTML transferred: 180000 bytes
Requests per second: 498.90 [#/sec] (mean)
Time per request: 20.044 [ms] (mean)
Time per request: 2.004 [ms] (mean, across all concurrent requests)
Transfer rate: 80.88 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.4 0 4
Processing: 3 19 5.4 19 46
Waiting: 3 19 5.3 19 46
Total: 5 20 5.3 19 47
Percentage of the requests served within a certain time (ms)
50% 19
66% 20
75% 22
80% 23
90% 27
95% 30
98% 34
99% 38
100% 47 (longest request)
= результат ======================
flup/uWSGI
Requests per second: 1 к 5
Transfer rate: 1 к 5
В основном 1 к 5!
http://habrahabr.ru/blogs/python/67475/
http://m.habrahabr.ru/post/70531/
---
Решил тут я попробывать веб-сервер cherokee для django-сайта. Обычно используется flup-прослойка, а я хотел задействовать uwsgi.
Что я сделал (опишу успешные шаги):
1. создал новый django-проект
2. создал новый app "dummy" с простым выводом:
def index(request):
return HttpResponse('hello from django!')
3. установил cherokee последнюю версию из svn (на сайте чероки описано как это сделать), т.к. в текущей 0.99.19 нет визарда для настройки uWSGI...4. сайты у меня находятся в каталоге /var/www-cherokee (владелец www-data)
5. в каталог django1 я скопировал свой проект.
6. в /var/www-cherokee нужно поместить uwsgi.xml - это конфигурационный файл для запуска джанго-сайта. содержание моего:
<uwsgi>
<pythonpath>/var/www-cherokee/</pythonpath>
<pythonpath>/var/www-cherokee/django1</pythonpath>
<app mountpoint="/">
<script>/django1/django_wsgi</script>
</app>
</uwsgi>
обратите внимание на пути в pythonpath - без них работать не будет.7. в /var/www-cherokee/django1 помещаем скрипт для вызова джанго (django_wsgi):
#some code for run on cherokee web server import os import django.core.handlers.wsgi os.environ['DJANGO_SETTINGS_MODULE'] = 'settings' application = django.core.handlers.wsgi.WSGIHandler()8. в настройках cherokee (в которые легко попасть через sudo cherokee-admin -u и потом в браузере http://localhost:9090) нужно в разделе "Virtual Server: default" вызвать "wizards"->platforms ->uWSGI ->run wizard.
так же в параметре "Interpreter" проверьте путь до конфига uwsgi.xml (у меня строка выглядит так: /usr/bin/uwsgi -s /tmp/cherokee-source11.sock -C -x /var/www-cherokee/uwsgi.xml )
В принципе - все. Перезапустил сервер и в браузере увидел "hello..."
П.С.: о сломанных копьях в процессе конфигурации я умолчу. если что - я настраивал по этому посту.
П.П.С: если что то не работает (я сначала получал только "uwsgi error" в браузере) - попробуйте запустить в окне терминала строчку из настройки интерпретатора (/usr/bin/uwsgi -s /tmp/cherokee-source11.sock -C -x /var/www-cherokee/uwsgi.xml) и не закрывая его обновить страницу в браузере. потом в терминале можно увидеть ошибки (я так нашел неправильно указанный путь)... ВНИМАНИЕ! после запуска интерпретатора в ручную нужно удалять файл /tmp/cherokee-source11.sock (в моем случае)!
---
тесты:
1. flup
2. uWSGI
= 1 =============
Document Length: 18 bytes
Concurrency Level: 10
Time taken for tests: 102.068 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 1660166 bytes
HTML transferred: 180018 bytes
Requests per second: 97.97 [#/sec] (mean)
Time per request: 102.068 [ms] (mean)
Time per request: 10.207 [ms] (mean, across all concurrent requests)
Transfer rate: 15.88 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 1.8 0 39
Processing: 3 101 241.3 39 3777
Waiting: 0 98 236.6 38 3777
Total: 3 102 241.3 40 3778
Percentage of the requests served within a certain time (ms)
50% 40
66% 56
75% 69
80% 79
90% 171
95% 292
98% 1125
99% 1226
100% 3778 (longest request)
= 2 =============
Document Length: 18 bytes
Concurrency Level: 10
Time taken for tests: 20.044 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 1660000 bytes
HTML transferred: 180000 bytes
Requests per second: 498.90 [#/sec] (mean)
Time per request: 20.044 [ms] (mean)
Time per request: 2.004 [ms] (mean, across all concurrent requests)
Transfer rate: 80.88 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.4 0 4
Processing: 3 19 5.4 19 46
Waiting: 3 19 5.3 19 46
Total: 5 20 5.3 19 47
Percentage of the requests served within a certain time (ms)
50% 19
66% 20
75% 22
80% 23
90% 27
95% 30
98% 34
99% 38
100% 47 (longest request)
= результат ======================
flup/uWSGI
Requests per second: 1 к 5
Transfer rate: 1 к 5
В основном 1 к 5!
пятница, 6 ноября 2009 г.
GAE | Свой домен
На текущий момент можно сделать только:
Раньше можно было добавить в ДНС-записи А-запись с адресами гугла, но теперь так не сработает. Решение только одно - нужно где-то разместить сайт для домена 2ого уровня и сделать на нем редирект на www.домен. Я пока не искал как проще и за сколько такое сделать - у меня есть где повесить сайт-редирект. Еще вариант - можно купить домен у самого гугла (я не проверял). Или воспользоваться Web-forwarding (у ру-центра он есть).
Я столкнулся с обычной настройкой "своего домена" на app в GAE. Ру-центр. Самое важное - нужно зарегистрироваться в службах Google, так как это единственная возможность привязать свой домен к GAE приложению (я по глупости пытался как "частное лицо" найти решение).
Далее - нужна услуга ДНС-мастер secondary.
Далее всё по гуглу. В службах Google нужно выполнить "подтверждение владением домена". И добавить в ДНС записи:
И учтите, что домен должен быть делегирован. Я по малоопытности прождал 2 дня. Потом погуляв по личному кабинету настройки доменов увидел, что нужный мне домен не делегирован...
www.ваш_домен.все
Раньше можно было добавить в ДНС-записи А-запись с адресами гугла, но теперь так не сработает. Решение только одно - нужно где-то разместить сайт для домена 2ого уровня и сделать на нем редирект на www.домен. Я пока не искал как проще и за сколько такое сделать - у меня есть где повесить сайт-редирект. Еще вариант - можно купить домен у самого гугла (я не проверял). Или воспользоваться Web-forwarding (у ру-центра он есть).
Я столкнулся с обычной настройкой "своего домена" на app в GAE. Ру-центр. Самое важное - нужно зарегистрироваться в службах Google, так как это единственная возможность привязать свой домен к GAE приложению (я по глупости пытался как "частное лицо" найти решение).
Далее - нужна услуга ДНС-мастер secondary.
Далее всё по гуглу. В службах Google нужно выполнить "подтверждение владением домена". И добавить в ДНС записи:
google_ваша_строка_даст_гугл СNAME google.com. www CNAME ghs.google.com.
И учтите, что домен должен быть делегирован. Я по малоопытности прождал 2 дня. Потом погуляв по личному кабинету настройки доменов увидел, что нужный мне домен не делегирован...
среда, 28 октября 2009 г.
DJANGO | Шаблоны | Свой фильтр в условиях GAE
О`кей. Расскажу как сделать свой фильтр для Django 0.96 (для работы в Google App Engine). Конечно на питоне!
1. в корне проекта создаем файл 'django_template_custom_filters.py':
2. В нужном контроллере (скрипт, который дергается по урл'у):
3. Теперь в шаблоне можно:
1. в корне проекта создаем файл 'django_template_custom_filters.py':
# coding: utf-8
from google.appengine.ext import webapp
register = webapp.template.create_template_register()
def fctitle(text):
"""
First char title
"""
result=''
if text and len(text)>0:
result=text[0]
result=result.title()+text.__getslice__(1,len(text))
return result
else:
return ''
register.filter(fctitle)
2. В нужном контроллере (скрипт, который дергается по урл'у):
webapp.template.register_template_library('django_template_custom_filters')
3. Теперь в шаблоне можно:
<h1>{{article.title|fctitle}}</h1>
четверг, 15 октября 2009 г.
Just-In-Time debugging. Error. Лечение
Нарвался на "секс" - при запуске различных программ вылезало предупреждение, что не установлен дебаггер Just-In-Time. Глупый микрософт предлагал исправить это через настройку в Visual Studio. Но! у меня express edition! OMG! Он этого не умеет!
Оказалось все просто. Обычно с рождения используется Dr.Watson. Так вот его просто нужно "вернуть"!
Оказалось все просто. Обычно с рождения используется Dr.Watson. Так вот его просто нужно "вернуть"!
drwtsn32 -i
пятница, 9 октября 2009 г.
PostgreSQL. Обычные ошибки при новой установке
Сегодня начал поднимать сервер на линуксе. Постгрес стоит. Свежий. Но с другой машины - не пускает.
1. Свежая установка постгреса не имеет пароля для пользователя postgres. Правится так:
1. Свежая установка постгреса не имеет пароля для пользователя postgres. Правится так:
su postgres psql alter user postgres with password ‘mypasswd’;2. Внешние коннекты могут быть настроены не правильно. pgAdmin может подсказать:
#pg_hba.conf host all all 192.168.0.0/24 md5
среда, 30 сентября 2009 г.
GAE. Bulkload. Загрузка дампа. Дата-время.
Если ваш дамп содержит поле дата-время вида 2000-05-30 23:15:34.943 то закачать можно только с конвертацией, например:
Причем миллисекунды - отсекаются. Т.к. питон 2.5 их не знает...
('When',lambda x: datetime.datetime.strptime(x.split('.')[0], '%Y-%m-%d %H:%M:%S')),
Причем миллисекунды - отсекаются. Т.к. питон 2.5 их не знает...
вторник, 29 сентября 2009 г.
понедельник, 28 сентября 2009 г.
GAE. Bulkload. Итог.
Жаль, но моё решение (на первый взгляд) - не использовать GAE.
Почему?:
* самое неприятное - ограничение на CPU.
причем его нельзя как-то запланировать и просчитать
* ограничение на селекты
в принципе - оно может и правильное, но как быть, если я хочу показывать, что у меня есть, например, 5000 объявлений в базе? про шардинг я читал - все это - изврат
* нет join`ов - не удобно работать (фильтровать) связанные объекты.
можно плодить дополнительные объекты - но ведь это костыли!!!
* огромное неприятное - нет возможности наблюдать на сервером.
например - когда упадет... когда держишь несколько машин - можно повесить вачдог, чтоб письмо на почту слал... или оптимизация кода...
* ждать индексации - издевательство
вот залил я дамп, хочу тест сделать - селект с фильтром по полю - фиг вам! нельзя, пока не построится индекс!!!
Ваши мысли - приветствуются
Почему?:
* самое неприятное - ограничение на CPU.
причем его нельзя как-то запланировать и просчитать
* ограничение на селекты
в принципе - оно может и правильное, но как быть, если я хочу показывать, что у меня есть, например, 5000 объявлений в базе? про шардинг я читал - все это - изврат
* нет join`ов - не удобно работать (фильтровать) связанные объекты.
можно плодить дополнительные объекты - но ведь это костыли!!!
* огромное неприятное - нет возможности наблюдать на сервером.
например - когда упадет... когда держишь несколько машин - можно повесить вачдог, чтоб письмо на почту слал... или оптимизация кода...
* ждать индексации - издевательство
вот залил я дамп, хочу тест сделать - селект с фильтром по полю - фиг вам! нельзя, пока не построится индекс!!!
Ваши мысли - приветствуются
GAE. Bulkload. Загрузка дампа. Русский язык.
Столкнулся с загрузкой дампа, в котором есть строки с русским языком. Загрузчик ругался...
Решение (пример, русский текст в свойстве Name. просто добавляем лямбда-функцию для конвертации)
Решение (пример, русский текст в свойстве Name. просто добавляем лямбда-функцию для конвертации)
class Organization_Shop(db.Model):
Id=db.StringProperty()
Name=db.StringProperty()
Deleted=db.BooleanProperty()
class Organization_Shop_Loader(Loader):
def __init__(self):
Loader.__init__(
self,
'Organization_Shop',
[('Id',str),
('Name',lambda x: unicode(x, 'utf-8')),
('Deleted',bool)]
)
четверг, 24 сентября 2009 г.
GAE. Bulkload. Загрузка дампа.
Изучаю Google App Engine. Тестирую. Столкнулся с необходимостью загрузить дамп таблицы. Много времени потратил, пытаясь сделать все по инструкции. Оказалось - она несколько устаревшая что-ли...
Публикую мой рабочий пример:
Конфиг app.yaml:
Класс для загрузки .csv - uploader.py (обратите внимание - класс bulkloader не подключен, в коде фигурирует просто Loader):
Дамп d.csv:
Вызов процесса аплоада дампа: (обратите внимание на то, что вызывается bulkloader.py - в текущей версии appcfg.py у меня не умеет делать аплоад! Вызов для удобства разбиваю на строки...)
Вот. Только так у меня сейчас и работает. Успехов!
Публикую мой рабочий пример:
Конфиг app.yaml:
application: fun-test version: 2 runtime: python api_version: 1 handlers: - url: /remote_api script: $PYTHON_LIB/google/appengine/ext/remote_api/handler.py login: admin - url: /.* script: main.py
Класс для загрузки .csv - uploader.py (обратите внимание - класс bulkloader не подключен, в коде фигурирует просто Loader):
# coding=UTF-8
import datetime
from google.appengine.ext import db
class Test(db.Model):
Name=db.StringProperty()
LastName=db.StringProperty()
class TestLoader(Loader):
def __init__(self):
Loader.__init__(
self,
'Test',
[('Name',str),
('LastName',str)]
)
loaders = [TestLoader]
Дамп d.csv:
Jonny, Lee Carl,Donny Nick,Cookie
Вызов процесса аплоада дампа: (обратите внимание на то, что вызывается bulkloader.py - в текущей версии appcfg.py у меня не умеет делать аплоад! Вызов для удобства разбиваю на строки...)
C:\Program Files\Google>c:\Python25\python.exe google_appengine/bulkloader.py --filename=testapp/d.csv --kind=Test --url=http://localhost:8080/remote_api --config_file=testapp/uploader.py --app_id=fun-test
Вот. Только так у меня сейчас и работает. Успехов!
вторник, 22 сентября 2009 г.
House, dr. s06e01
а-ха-ха-ха! супер. в моих липких лапках Хаус 6.1+2
в заставке - композиция радиохеад! (оччень хорошая)
Видео
в заставке - композиция радиохеад! (оччень хорошая)
Видео
понедельник, 7 сентября 2009 г.
среда, 12 августа 2009 г.
MSSQL: вставка большого кол-ва строк в таблицу с триггером
Наткнулся на большие задержки локов на важных таблицах. Оказалось если на таблице висит триггер на вставку, и вставить много-много строк (в моём случае было около 50 000) - очень долго выполняется вставка (около 30 сек). Лечится временным выключением триггера (если это позволительно логикой триггера):
Включение - enable.
disable [trigger_name] on [table_name];
Включение - enable.
пятница, 3 июля 2009 г.
Windows. Удаленный вход. Терминальная лицензия - обход
Админы люди ленивые. Кончился "льготный" период пользования терминальным сервисом - не пускает. Но если очень нужно - то можно:
mstsc /v:192.168.0.1 /console
пятница, 29 мая 2009 г.
Для тех, у кого есть вопросы касательно plProxy\pbBouncer
... изниняйте!, я еще не перешел к внедрению в своих проектах, т.к. занят программой-репликатором MSSQL-2-PostgreSQL... и по этому ничего путного не знаю (кроме моих переводов)...
пятница, 24 апреля 2009 г.
MSSQL: Поиск по текстам хранимых процедур
При написании программы-репликатора mssql-to-postgresql, столкнулся с необходимостью найти все хранимые процедуры, где используется какая-либо таблица.
Решение:
Решение:
SELECT ROUTINE_NAME, ROUTINE_DEFINITION
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_DEFINITION LIKE '%искомый текст%'
AND ROUTINE_TYPE='PROCEDURE'
пятница, 17 апреля 2009 г.
WINDOWS: Синхронизация времени
Для синхронизации времени между серверами в сети я обычно делаю timesync.bat в корне диска C
и делаю задание в шедулере (Scheduled Tasks) на запуск этого bat`ника каждое утро...
NET TIME \\имя_мастер_сервера /SET /YES
и делаю задание в шедулере (Scheduled Tasks) на запуск этого bat`ника каждое утро...
MSSQL: Бекап на другую машину по сети
Зачем?
Как?
1. Установить сетевое устройство для бекапа можно только запросом
Памятка: нужно указывать полный путь до файла!
2. Проще создать хранимую процедуру для вызова бекап-процесса
Памятка: имя файла реально не важно. т.к. сервер считает устройство чем-то типа 'Tape'.
3. На сервере-хранителе бекапа нужно на шару поставить разрешения на запись для пользователя сервер-с-бд\имя_юзера (например sql)
4. На сервере-бд создать такого же юзера.
5. ОЧЕНЬ ВАЖНО - нужно, что бы MSSQL-сервер (служба) запускалась под созданным выше юзером. Т.к. иначе не будет доступа к 'шаре' (расшаренному каталогу на другом сервере).
6. Сделать службу (Job). В адвансед-свойствах шага поставить запуск под юзером (см. выше).
- Нехватка места на локальном сервере
- FailOver (если накроется сервер - бекап останется)
Как?
1. Установить сетевое устройство для бекапа можно только запросом
USE master;
GO
EXEC sp_addumpdevice ’disk’, ’networkdevice’,
’\\<servername>\<sharename>\<path>\<filename>.bak’
Памятка: нужно указывать полный путь до файла!
2. Проще создать хранимую процедуру для вызова бекап-процесса
BACKUP DATABASE [ваша_бд] TO
[networkdevice] WITH NOFORMAT, INIT,
NAME = N'имя_файла_не_важно', SKIP, REWIND, NOUNLOAD, STATS = 10;
Памятка: имя файла реально не важно. т.к. сервер считает устройство чем-то типа 'Tape'.
3. На сервере-хранителе бекапа нужно на шару поставить разрешения на запись для пользователя сервер-с-бд\имя_юзера (например sql)
4. На сервере-бд создать такого же юзера.
5. ОЧЕНЬ ВАЖНО - нужно, что бы MSSQL-сервер (служба) запускалась под созданным выше юзером. Т.к. иначе не будет доступа к 'шаре' (расшаренному каталогу на другом сервере).
6. Сделать службу (Job). В адвансед-свойствах шага поставить запуск под юзером (см. выше).
среда, 15 апреля 2009 г.
pgBouncer - Установка
Лучше всего взять новую версию и откомпилировать её. http://pgfoundry.org/projects/pgbouncer. Так же заметил присутствие в репозиториях Убунты.
make и make install прошли успешно.
Но для самосборной версии нужно:
- сделать конфиг
- создать скрипт запуска в /etc/init.d/
Конфиг: (/etc/pgBouncer/pgbouncer.ini)
Скрипт:
(Исходник в папке /etc исходников. Я менял пути в начале скрипта...)
Для автозапуска сделать файл pgbouncer gj пути /etc/default/ с содержимым:
Теперь подключатся нужно к порту 6432 (Он, кстати, стал стандартом...).
Вобщем у меня всё заработало.
Для просмотра диагностики pgBouncer`a
Список команд - тут.
Для затравки:
show help;
show pools;
show clients;
make и make install прошли успешно.
Но для самосборной версии нужно:
- сделать конфиг
- создать скрипт запуска в /etc/init.d/
Конфиг: (/etc/pgBouncer/pgbouncer.ini)
;; database name = connect string [databases] test = host=127.0.0.1 port=5432 dbname=test ;;ОБЯЗАТЕЛЬНО db postgres postgres= host=127.0.0.1 port=5432 dbname=postgres ; foodb over unix socket foodb = ; redirect bardb to bazdb on localhost ;bardb = host=127.0.0.1 dbname=bazdb ; acceess to dest database will go with single user ;forcedb = host=127.0.0.1 port=300 user=baz password=foo client_encoding=UNICODE datestyle=ISO connect_query='SELECT 1' nondefaultdb = pool_size=50 reserve_pool=10 ; fallback connect string ;* = host=testserver ;; Configuation section [pgbouncer] ;;; ;;; Administrative settings ;;; logfile = /var/log/pgBouncer/pgbouncer.log pidfile = /var/run/postgresql/pgbouncer.pid ;;; ;;; Where to wait for clients ;;; ; ip address or * which means all ip-s listen_addr = * listen_port = 6432 unix_socket_dir = /var/run/postgresql ;;; ;;; Authentication settings ;;; ; any, trust, plain, crypt, md5 auth_type = plain #auth_file = 8.0/main/global/pg_auth auth_file = /etc/pgBouncer/userlist.txt ;;; ;;; Users allowed into database 'pgbouncer' ;;; ; comma-separated list of users, who are allowed to change settings ; user1, user2 admin_users = postgres ; comma-separated list of users who are just allowed to use SHOW command stats_users = stats, root ;;; ;;; Pooler personality questions ;;; ; When server connection is released back to pool: ; session - after client disconnects ; transaction - after transaction finishes ; statement - after statement finishes pool_mode = session ; ; Query for cleaning connection immidiately after releasing from client. ; ; Query for 8.3+: ; DISCARD ALL; ; ; Older versions: ; RESET ALL; SET SESSION AUTHORIZATION DEFAULT ; server_reset_query = ; ; Comma-separated list of parameters to ignore when given ; in startup packet. Newer JDBC versions require the ; extra_float_digits here. ; ;ignore_startup_parameters = extra_float_digits ; ; When taking idle server into use, this query is ran first. ; SELECT 1 ; server_check_query = select 1 ; If server was used more recently that this many seconds ago, ; skip the check query. Value 0 may or may not run in immidiately. server_check_delay = 10 ;;; ;;; Connection limits ;;; ; total number of clients that can connect max_client_conn = 100 default_pool_size = 20 ; how many additional connection to allow in case of trouble reserve_pool_size = 5 ; if a clients needs to wait more than this many seconds, use reserve pool ;reserve_pool_timeout = 3 log_connections = 1 log_disconnections = 1 ; log error messages pooler sends to clients log_pooler_errors = 1 ; If off, then server connections are reused in LIFO manner ;server_round_robin = 0 ;;; ;;; Timeouts ;;; ;; Close server connection if its been connected longer. ;server_lifetime = 1200 ;; Close server connection if its not been used in this time. ;; Allows to clean unneccessary connections from pool after peak. ;server_idle_timeout = 60 ;; Cancel connection attepmt if server does not answer takes longer. ;server_connect_timeout = 15 ;; If server login failed (server_connect_timeout or auth failure) ;; then wait this many second. ;server_login_retry = 15 ;; Dangerous. Server connection is closed if query does not return ;; in this time. Should be used to survive network problems, ;; _not_ as statement_timeout. (default: 0) ;query_timeout = 0 ;; Dangerous. Client connection is closed if no activity in this time. ;; Should be used to survive network problems. (default: 0) ;client_idle_timeout = 0 ;; Disconnect clients who have not managed to log in after connecting ;; in this many seconds. ;client_login_timeout = 60 ;; Clean automatically created database entries (via "*") if they ;; stay unused in this many seconds. ; autodb_idle_timeout = 3600 ;;; ;;; Low-level tuning options ;;; ;; buffer for streaming packets ;pkt_buf = 2048 ;; networking options, for info: man 7 tcp ;; linux: notify program about new connection only if there ;; is also data received. (Seconds to wait.) ;; On Linux the default is 45, on other OS'es 0. ;tcp_defer_accept = 0 ;; In-kernel buffer size (linux default: 4096) ;tcp_socket_buffer = 0 ;; whether tcp keepalive should be turned on (0/1) ;tcp_keepalive = 0 ;; following options are linux-specific. ;; they also require tcp_keepalive=1 ;; count of keepaliva packets ;tcp_keepcnt = 0 ;; how long the connection can be idle, ;; before sending keepalive packets ;tcp_keepidle = 0 ;; The time between individual keepalive probes. ;tcp_keepintvl = 0
Скрипт:
(Исходник в папке /etc исходников. Я менял пути в начале скрипта...)
#!/bin/bash
#
# pgbouncer Start the PgBouncer PostgreSQL pooler.
#
# The variables below are NOT to be changed. They are there to make the
# script more readable.
NAME=pgbouncer
DAEMON=/usr/local/bin/$NAME
PIDFILE=/var/run/postgresql/$NAME.pid
CONF=/etc/pgBouncer/$NAME.ini
OPTS="-d $CONF -u postgres"
# note: SSD is required only at startup of the daemon.
SSD=`which start-stop-daemon`
ENV="env -i LANG=C PATH=/bin:/usr/bin:/usr/local/bin"
trap "" 1
# Check if configuration exists
test -f $CONF || exit 0
case "$1" in
start)
echo -n "Starting server: $NAME"
$ENV $SSD --start --pidfile $PIDFILE --exec $DAEMON -- $OPTS > /dev/null
;;
stop)
echo -n "Stopping server: $NAME"
start-stop-daemon --stop --pidfile $PIDFILE
;;
reload | force-reload)
echo -n "Reloading $NAME configuration"
start-stop-daemon --stop --pidfile $PIDFILE --signal HUP
;;
restart)
$0 stop
$0 start
;;
*)
echo "Usage: /etc/init.d/$NAME {start|stop|reload|restart}"
exit 1
;;
esac
if [ $? -eq 0 ]; then
echo .
exit 0
else
echo " failed"
exit 1
fi
Для автозапуска сделать файл pgbouncer gj пути /etc/default/ с содержимым:
START=1
Теперь подключатся нужно к порту 6432 (Он, кстати, стал стандартом...).
Вобщем у меня всё заработало.
Для просмотра диагностики pgBouncer`a
sudo psql -p 6432 pgbouncer -U postgres
Список команд - тут.
Для затравки:
show help;
show pools;
show clients;
PlProxy - установка на убунту 8
Пришло время попробовать PlProxy.
Для начала - нужно его установить:
Нужно скачать последнюю версию с http://pgfoundry.org/projects/plproxy и распаковать её (я распаковал в /tmp/plproxy).
Далее в описании процесса инсталляции сказано сделать
...но мне ругалось на ошибки.
Как оказалось нужно еще установить кое-что:
После этого нормально проходит
Но на make installcheck мне ругнулось, что типа постгрес не отвечает на стандартном порту. Ну ладно. Я сделал далее как следует:
Конечно же БД test уже существовала. Ругнулось на отсутствие пользователя root. Поскольку это тестирование - я выстренько сделал суперпользователя root в БД.
Далее я создал еще одну БД ro1.
В БД ro1 создал таблицу Test_1
Вставил несколько строк (руками).
Потом проверил работу plproxy-языка.
Это в БД test:
Теперь с БД test выполняю
И получаю ответ (не буду его приводить) - значит все работает!
Для начала - нужно его установить:
Нужно скачать последнюю версию с http://pgfoundry.org/projects/plproxy и распаковать её (я распаковал в /tmp/plproxy).
Далее в описании процесса инсталляции сказано сделать
make
...но мне ругалось на ошибки.
Как оказалось нужно еще установить кое-что:
sudo apt-get install libpq-dev
sudo apt-get install postgresql-server-dev-8.3
sudo apt-get install flex
sudo apt-get install bison
После этого нормально проходит
make
make install
Но на make installcheck мне ругнулось, что типа постгрес не отвечает на стандартном порту. Ну ладно. Я сделал далее как следует:
psql -f /usr/share/contrib/plproxy.sql test
Конечно же БД test уже существовала. Ругнулось на отсутствие пользователя root. Поскольку это тестирование - я выстренько сделал суперпользователя root в БД.
Далее я создал еще одну БД ro1.
В БД ro1 создал таблицу Test_1
CREATE TABLE test_1
(
"Id" serial NOT NULL,
"Name" character varying(400) NOT NULL,
CONSTRAINT pk_id PRIMARY KEY ("Id")
)
WITH (OIDS=FALSE);
ALTER TABLE test_1 OWNER TO postgres;
Вставил несколько строк (руками).
Потом проверил работу plproxy-языка.
Это в БД test:
create or replace function test_plproxy(i_text text)
returns setof text as $$
connect 'dbname=ro1';
select "Name" from Test_1 where "Id"=1;
--select $1;
$$ language plproxy;
Теперь с БД test выполняю
select test_plproxy('zzz');
И получаю ответ (не буду его приводить) - значит все работает!
вторник, 7 апреля 2009 г.
Ubuntu - Tahoma.ttf
Поскольку я занимаюсь и версткой - мне крайне необходим шрифт тахома в Убунте.
Оказалось он есть в wine. Так что я установил wine
Потом копируем 2 шрифта из
После перезапуска FireFox нормально отображал этот шрифт.
Оказалось он есть в wine. Так что я установил wine
sudo api-get install wine
Потом копируем 2 шрифта из
/usr/share/wine/fonts/ (tahoma*)в
~/.fonts(вроде можно и в /usr/share/fonts/truetype/ttf-liberation) и выполняем
fc-cache -fv
После перезапуска FireFox нормально отображал этот шрифт.
Lenovo s10 | Вот я и купил себе лаптоп!
В реальности выглядит намного лучше, чем на фотках! Покупал на озоне, весь черный.
Установил убунту 9. всё заработало кроме микрофона встроенного. Но тут есть решение. (Нужно зарегистрироваться и скачать alsa-upgrade. Запустить с ключем -di - скрипт скачает нужные файлы и откомпилирует их, и установит.)
Потом обязательно перезапуск. В настройках аудио появится вкладка "Запись" - там переключить захват на микрофон.
После этого в скайпе всё ок!!!
- 1 Гб памяти
- 160 Гб на диске
- расширенная батарея!
Установил убунту 9. всё заработало кроме микрофона встроенного. Но тут есть решение. (Нужно зарегистрироваться и скачать alsa-upgrade. Запустить с ключем -di - скрипт скачает нужные файлы и откомпилирует их, и установит.)
Потом обязательно перезапуск. В настройках аудио появится вкладка "Запись" - там переключить захват на микрофон.
После этого в скайпе всё ок!!!
воскресенье, 29 марта 2009 г.
[Перевод] PostgreSQL кластер: партишинг с plproxy (часть 2)
оригинал в блоге Kristo Kaiv
В предыдущем посте я описал как установить plproxy и сделать базовый вариант горизонтального кластера.
Теперь взглянем на другое типичное применение в жизни: создание кластера только-чтение для вашей БД.
Разделение нагрузки на чтение.
Самое простое использование в жизни для plproxy - использование для перенаправления запросов только-чтение на реплики "только-чтение" основной БД. Реплицированые БД могут быть заполнены данными с помощью Londiste из пакета SkyTools. Описание установки может быть найдено тут. Или можно использовать Slony, который является более тяжелым решением и из моего опыта так же более труден в установке и поддержке, хотя и лучше документирован.
Типичный кластер "только-чтение" изображен на схеме
БД со знаком "p" имеют пул соединений. Мы используем PgBouncer но pgpool тоже хорошее решение.
Пулы нужны для оптимизации кол-ва соединений с базами, плюс планы выполнения запросов кэшируются на основе выбранного соединения. Конечно все будет работать и без пулов. Пунктирные линии на схеме - реплики.
В этой установке plproxy-функции определяют базу, к которой нужно перенаправить запрос. Запросы на чтение-запись идут к мастер-базе, а только-чтение к репликам "только-н-чтение".
Настройка репликации проста, как только вы пройдете сложный процесс установки утилит skytools.
Первое - давайте создадим конфигурацию для реплик и мастер-базы:
файл replica1.ini
[londiste]
job_name = londiste_master_to_r1
provider_db = dbname=write
subscriber_db = dbname=ro1
# значение будет использовано как идентификатор, так что не используйте точки и пробелы
pgq_queue_name = londiste.write
pidfile = %(job_name)s.pid
logfile = %(job_name)s.log
use_skylog = 0
Файл replica2.ini практически такой же, только название задания и имя базы нужно изменить. Теперь установим Londiste на провайдере (мастер-базе) и подписчиках (r01, r02) и запусим демонов (службы) репликации:
mbpro:~/temp kristokaiv$ londiste.py replica1.ini provider install
mbpro:~/temp kristokaiv$ londiste.py replica1.ini subscriber install
mbpro:~/temp kristokaiv$ londiste.py replica2.ini subscriber install
mbpro:~/temp kristokaiv$ londiste.py replica1.ini replay -d
mbpro:~/temp kristokaiv$ londiste.py replica2.ini replay -d
Теперь нужно настроить тикер-процесс на базе данных, на которой производится запись. Тикер создает события синхронизации, так что чем чаще он запускается - тем меньше разницы в бд ro. Мой конфиг выглядит так:
файл ticker_write.ini
[pgqadm]
job_name = ticker_write
db = dbname=write
# как часто запусткать задачу [минуты]
maint_delay_min = 1
# как часто проверять активность [секунды]
loop_delay = 0.1
logfile = %(job_name)s.log
pidfile = %(job_name)s.pid
use_skylog = 0
Для запуска тикера как демон (служба) выполните:
mbpro:~/temp kristokaiv$ pgqadm.py ticker_write.ini ticker -d
Давайте создадим простую таблицу, которую мы будем реплицировать с мастера на репликантов "только-чтение".
mbpro:~/temp kristokaiv$ psql -c "CREATE TABLE users (username text primary key, password text);" write
mbpro:~/temp kristokaiv$ psql -c "CREATE TABLE users (username text primary key, password text);" ro1
mbpro:~/temp kristokaiv$ psql -c "CREATE TABLE users (username text primary key, password text);" ro2
Добавляем её к репликации
mbpro:~/temp kristokaiv$ londiste.py replica1.ini provider add users
mbpro:~/temp kristokaiv$ londiste.py replica1.ini subscriber add users
mbpro:~/temp kristokaiv$ londiste.py replica2.ini subscriber add users
Спустя некоторое время таблицы должны засинхронизироваться. Вставим новую запись в таблицу и проверим - появилась ли запись на обоих репликантах.
Функции для вставки и выборки из таблицы users:
Только для комфорта тех, кто реально попробует повторить эти шаги, привожу конфигурацию прокси-бд:
cluster config:
Последнее что осталось сделать - создать plproxy-функцию, которая перенаправляет вызов функции логина на бд только-чтение и функцию add_user на бд для записи (мастер).
Вот и всё. кластер готов! Учтите, что хотя создание кластера только-чтение выглядит просто и как быстрое решение для ваших проблем с производительностью - это не решение "серебряная пуля".
Асинхронная репликация часто создает больше проблем чем решает. Так что будте осторожнее - реплицируйте только не критичную ко времени информацию. Или гарантируйте запасное решение когда данные не найдены (например - прокси функция сначала проверяет базу только-чтение и если данные не найдены - ищет их в мастер-базе).
В предыдущем посте я описал как установить plproxy и сделать базовый вариант горизонтального кластера.
Теперь взглянем на другое типичное применение в жизни: создание кластера только-чтение для вашей БД.
Разделение нагрузки на чтение.
Самое простое использование в жизни для plproxy - использование для перенаправления запросов только-чтение на реплики "только-чтение" основной БД. Реплицированые БД могут быть заполнены данными с помощью Londiste из пакета SkyTools. Описание установки может быть найдено тут. Или можно использовать Slony, который является более тяжелым решением и из моего опыта так же более труден в установке и поддержке, хотя и лучше документирован.
Типичный кластер "только-чтение" изображен на схеме
БД со знаком "p" имеют пул соединений. Мы используем PgBouncer но pgpool тоже хорошее решение.
Пулы нужны для оптимизации кол-ва соединений с базами, плюс планы выполнения запросов кэшируются на основе выбранного соединения. Конечно все будет работать и без пулов. Пунктирные линии на схеме - реплики.
В этой установке plproxy-функции определяют базу, к которой нужно перенаправить запрос. Запросы на чтение-запись идут к мастер-базе, а только-чтение к репликам "только-н-чтение".
Настройка репликации проста, как только вы пройдете сложный процесс установки утилит skytools.
Первое - давайте создадим конфигурацию для реплик и мастер-базы:
файл replica1.ini
[londiste]
job_name = londiste_master_to_r1
provider_db = dbname=write
subscriber_db = dbname=ro1
# значение будет использовано как идентификатор, так что не используйте точки и пробелы
pgq_queue_name = londiste.write
pidfile = %(job_name)s.pid
logfile = %(job_name)s.log
use_skylog = 0
Файл replica2.ini практически такой же, только название задания и имя базы нужно изменить. Теперь установим Londiste на провайдере (мастер-базе) и подписчиках (r01, r02) и запусим демонов (службы) репликации:
mbpro:~/temp kristokaiv$ londiste.py replica1.ini provider install
mbpro:~/temp kristokaiv$ londiste.py replica1.ini subscriber install
mbpro:~/temp kristokaiv$ londiste.py replica2.ini subscriber install
mbpro:~/temp kristokaiv$ londiste.py replica1.ini replay -d
mbpro:~/temp kristokaiv$ londiste.py replica2.ini replay -d
Теперь нужно настроить тикер-процесс на базе данных, на которой производится запись. Тикер создает события синхронизации, так что чем чаще он запускается - тем меньше разницы в бд ro. Мой конфиг выглядит так:
файл ticker_write.ini
[pgqadm]
job_name = ticker_write
db = dbname=write
# как часто запусткать задачу [минуты]
maint_delay_min = 1
# как часто проверять активность [секунды]
loop_delay = 0.1
logfile = %(job_name)s.log
pidfile = %(job_name)s.pid
use_skylog = 0
Для запуска тикера как демон (служба) выполните:
mbpro:~/temp kristokaiv$ pgqadm.py ticker_write.ini ticker -d
Давайте создадим простую таблицу, которую мы будем реплицировать с мастера на репликантов "только-чтение".
mbpro:~/temp kristokaiv$ psql -c "CREATE TABLE users (username text primary key, password text);" write
mbpro:~/temp kristokaiv$ psql -c "CREATE TABLE users (username text primary key, password text);" ro1
mbpro:~/temp kristokaiv$ psql -c "CREATE TABLE users (username text primary key, password text);" ro2
Добавляем её к репликации
mbpro:~/temp kristokaiv$ londiste.py replica1.ini provider add users
mbpro:~/temp kristokaiv$ londiste.py replica1.ini subscriber add users
mbpro:~/temp kristokaiv$ londiste.py replica2.ini subscriber add users
Спустя некоторое время таблицы должны засинхронизироваться. Вставим новую запись в таблицу и проверим - появилась ли запись на обоих репликантах.
Функции для вставки и выборки из таблицы users:
CREATE OR REPLACE FUNCTION public.add_user(
in i_username text,
in i_password text,
out status_code text
) AS $$
BEGIN
PERFORM 1 FROM users WHERE username = i_username;
IF NOT FOUND THEN
INSERT INTO users (username, password) VALUES (i_username, i_password);
status_code = 'OK';
ELSE
status_code = 'user exists';
END IF;
RETURN;
END; $$ LANGUAGE plpgsql SECURITY DEFINER;
GRANT EXECUTE ON FUNCTION public.add_user(
in i_username text,
in i_password text,
out status_code text
) TO plproxy;
CREATE OR REPLACE FUNCTION login(
in i_username text,
in i_password text,
out status_code text
) AS $$
BEGIN
SELECT 'OK' FROM users u WHERE username = i_username AND password = i_password INTO status_code;
IF NOT FOUND THEN status_code = 'FAILED'; END IF;
RETURN;
END; $$ LANGUAGE plpgsql SECURITY DEFINER;
GRANT EXECUTE ON FUNCTION login(
in i_username text,
in i_password text,
out status_code text
) TO plproxy;
Только для комфорта тех, кто реально попробует повторить эти шаги, привожу конфигурацию прокси-бд:
cluster config:
CREATE OR REPLACE FUNCTION plproxy.get_cluster_partitions (cluster_name text)
RETURNS SETOF text AS $$
BEGIN
IF cluster_name = 'readonly' THEN
RETURN NEXT 'host=127.0.0.1 dbname=ro1';
RETURN NEXT 'host=127.0.0.1 dbname=ro2';
RETURN;
ELSIF cluster_name = 'write' THEN
RETURN NEXT 'host=127.0.0.1 dbname=write';
RETURN;
END IF;
RAISE EXCEPTION 'no such cluster%', cluster_name;
END; $$ LANGUAGE plpgsql SECURITY DEFINER;
CREATE OR REPLACE FUNCTION plproxy.get_cluster_config(
in cluster_name text,
out key text,
out val text)
RETURNS SETOF record AS $$
BEGIN
RETURN;
END;
$$ LANGUAGE plpgsql;
CREATE OR REPLACE FUNCTION plproxy.get_cluster_version(cluster_name text) RETURNS int AS $$
SELECT 1;
$$ LANGUAGE SQL;
Последнее что осталось сделать - создать plproxy-функцию, которая перенаправляет вызов функции логина на бд только-чтение и функцию add_user на бд для записи (мастер).
CREATE OR REPLACE FUNCTION public.login(
in i_username text,
in i_password text,
out status_code text
) AS $$
CLUSTER 'readonly'; RUN ON ANY;
$$ LANGUAGE plproxy;
CREATE OR REPLACE FUNCTION public.add_user(
in i_username text,
in i_password text,
out status_code text
) AS $$
CLUSTER 'write';
$$ LANGUAGE plproxy;
Вот и всё. кластер готов! Учтите, что хотя создание кластера только-чтение выглядит просто и как быстрое решение для ваших проблем с производительностью - это не решение "серебряная пуля".
Асинхронная репликация часто создает больше проблем чем решает. Так что будте осторожнее - реплицируйте только не критичную ко времени информацию. Или гарантируйте запасное решение когда данные не найдены (например - прокси функция сначала проверяет базу только-чтение и если данные не найдены - ищет их в мастер-базе).
[Перевод] PostgreSQL кластер: партишинг с plproxy (часть 1)
оригинал в блоге Kristo Kaiv
мой перевод на http://translated.by/you
Skype разработал много полезных утилит для создания кластера баз данных и эта серия публикаций прольет свет на ранее недокументированный функционал. В основе - plproxy. Лучшая фраза описать функциональность - "dblink на стероидах". Это короткое пособие объяснит, как установить plproxy, написать простые запросы к БД и установить простое горизонтальное масштабирование.
Партишинг для чайников.
Партишинг позволяет вам распределить загрузку БД и сами данные между несколькими серверами. Принцип прост. Допустим вы имеете одну таблицу, которая содержит данные на пользователей. Но проблема - миллионы пользователей ежедневно входят по своим аккаунтам в систему. Это создает большую загрузку сервера, не говоря о огромных размерах БД. Первое - нужно определить критерий, по которому мы будем выбирать на каком сервере содержатся данные. Мы можем сделать это по первому символу и имени пользователя. Пользователи a-j попадают в первый сервер, а k-z во второй. Это будет работать. Но скорее всего нагрузка на серверы будет не равномерной. Распространенное решение - использовать партишинг основываясь на хэше первичного ключа, в нашем случае - имени пользователя. Использование хэша позволит размещать записи более равномерно между серверами. То, что вам нужно знать про функцию хэша - это то, что она просто вычисляет номер, основанный на любом введённом значении.
Пример:
select hashtext('kristokaiv1') = 1116512480
select hashtext('kristokaiv2') = 1440348351
select hashtext('kristokaiv3') = -219299073
Объяснение, как это работает - выходит за рамки этого пособия.
Итак, допустим мы имеем 2 партиции, так что мы можем получить номер партиции основываясь на хэше имени пользователя.
Пример: partition nr = hashtext($1) & 1
&1 даст нам последний бит номера, который может быть 0 или 1. Это номер, которым мы можем выбрать партицию, на которой будут сохранены данные. Если 0 - данные попадут на партицию 0 и если 1 - на партицию 1.
select hashtext('kristokaiv1') & 1 = 0 -> partition 0
select hashtext('kristokaiv2') & 1 = 1 -> partition 1
select hashtext('kristokaiv3') & 1 = 1 -> partition 1
Как работает plproxy.
Концепция очень проста - plproxy это новый язык для запросов в PostgreSQL БД, который позволяет делать запросы к удаленным БД также как это делает dblink. Синтаксис очень прост - следующий запрос создает новую plproxy-функцию в БД, которая при запуске подключится в БД remotedb, выполнит функцию get_user_email(text) и вернет результаты.
localdb=#
CREATE FUNCTION get_user_email(username text) RETURNS text AS $$
CONNECT 'dbname=remotedb host=123.456.123.21 user=myuser';
$$ LANGUAGE plproxy;
Создадим функцию-пустышку в remotedb, которая будет отвечать на запрос
remotedb=#
create function get_user_email(text)
returns text as $$
select 'me@somewhere.com'::text;
$$ language sql;
При выполнении мы получим те же результаты, которые получаем по запросу на remotedb
localdb=#
select * from get_user_email('tere');
get_user_email
------------------
me@somewhere.com
(1 row)
Конечно это только простой пример и я вернусь к более сложному синтаксу позже. Давайте посмотрим, как установить plproxy-язык.
Установка plproxy.
Загрузить код можно с http://pgfoundry.org/projects/plproxy/ но я советую взять свежую версию из CVS (системы контроля версий).
Должен быть установлен набор разработки PostgreSLQ. Каталог, где расположена утилита конфигурации постгреса (pg_config), должен быть включен в переменную $PATH.
При этих условиях установка сводится к:
$ make
$ make install
$ make installcheck
Если у вас не получается заставить это работать - вы всегда можете попросить помощи. Финальный шаг - установить язык в БД. Это нельзя сделать как с другими языками (пользуясь утилитой createlang). Вы должны выполнить файл plproxy.sql, который создаст обработчик языка.
Файл plproxy.sql должен быть где-то в каталоге contrib.
$ psql -f /usr/local/pgsql/share/contrib/plproxy.sql queries
CREATE FUNCTION
CREATE LANGUAGE
Всё. Можно проверить установку простой plproxy-функцией (см. в синтаксических примерах).
Установка первого кластера.
Давайте создадим простой кластер, который будет состоять из 3 БД (в моем примере они все используют один и тот же вариант PostgreSQL). Одна прокси-БД вызывает запросы и две разделенные БД (партиции) с данными. Горизантальное разделение сделано на основе имени пользователя. Это часто используемый способ, т.к. большинство данных в БД - это связанные с пользователем: логин, заказы, платы, настройки...
Настройка Кластера.
Настройки БД кластеров хранятся внутри plpgsql-функций, которые вызывает плпрокси.
Существует 3 функции, которые вы должны создать для правильной конфигурации. Давайте создадим их в БД прокси.
1) plproxy.get_cluster_version(cluster_name text)
Эта функция вызывается при каждом запросе и она используется для отслеживания изменений конфигурации кластера (если возвращаемый ей номер больше, чем закешированное значение - конфигурация перезагружается). Давайте начнем с первой версии конфигурации. Пример:
CREATE OR REPLACE FUNCTION plproxy.get_cluster_version(cluster_name text) RETURNS int AS $$
BEGIN
IF cluster_name = 'queries' THEN
RETURN 1;
END IF;
END;
$$ LANGUAGE plpgsql;
2) plproxy.get_cluster_partitions(cluster_name text)
Эта функция должна возвращать строки для соединения для всех партиций в правильном порядке.
Из-за необоснованного ограничения общее кол-во должно быть кратно 2. Это необоснованное ограничение можно легко обойти, но это будет объяснено в другой раз.
CREATE OR REPLACE FUNCTION plproxy.get_cluster_partitions(cluster_name text) RETURNS SETOF text AS $$
BEGIN
IF cluster_name = 'queries' THEN
RETURN NEXT 'host=127.0.0.1 dbname=queries_0000';
RETURN NEXT 'host=127.0.0.1 dbname=queries_0001';
RETURN;
END IF;
RAISE EXCEPTION 'no such cluster: %', cluster_name;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
Если в строке соединения не указан логин для БД, будет использован текущий (CURRENT_USER). Так как плпрокси не знает ни одного пароля, разделенные БД должны разрешать соединения от БД прокси.
3)plproxy.get_cluster_config(cluster_name text)
Это эквивалент инициализационного файла. Функция должна возвращать параметры как пары ключь-значение. Все они - не обязательные, но нужно определить функцию-пустышку:
CREATE OR REPLACE FUNCTION plproxy.get_cluster_config (cluster_name text, out key text, out val text)
RETURNS SETOF record AS $$
BEGIN
RETURN;
END;
$$ LANGUAGE plpgsql;
Более подробно о параметрах и что они делают - читайте в документации plproxy.
Теперь установка завершена и можно начать "играть" с нашим новым кластером.
Давайте создадим новую таблицу для хранения имен пользователей (логинов) на обеих партициях.
#queries_0000=# CREATE TABLE users (username text PRIMARY KEY);
#queries_0001=# CREATE TABLE users (username text PRIMARY KEY);
Также нужно создать новую функцию, которая будет добавлять новые имена пользователей в таблицу:
CREATE OR REPLACE FUNCTION insert_user(i_username text) RETURNS text AS $$
BEGIN
PERFORM 1 FROM users WHERE username = i_username;
IF NOT FOUND THEN
INSERT INTO users (username) VALUES (i_username);
RETURN 'user created';
ELSE
RETURN 'user already exists';
END IF;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
Теперь давайте создадим прокси-функцию в БД прокси, которая будет вызывать запросы на партициях.
queries=#
CREATE OR REPLACE FUNCTION insert_user(i_username text) RETURNS TEXT AS $$
CLUSTER 'queries'; RUN ON hashtext(i_username);
$$ LANGUAGE plproxy;
Заполнение партиций случайными данными:
SELECT insert_user('user_number_'||generate_series::text) FROM generate_series(1,10000);
Теперь, если мы посмотрим во все БД мы увидим, что обе заполнены и заполнение почти равномерное.
queries_0001 count(*) -> 5071
queries_0000 count(*) -> 4930
Продолжение следует...
мой перевод на http://translated.by/you
Skype разработал много полезных утилит для создания кластера баз данных и эта серия публикаций прольет свет на ранее недокументированный функционал. В основе - plproxy. Лучшая фраза описать функциональность - "dblink на стероидах". Это короткое пособие объяснит, как установить plproxy, написать простые запросы к БД и установить простое горизонтальное масштабирование.
Партишинг для чайников.
Партишинг позволяет вам распределить загрузку БД и сами данные между несколькими серверами. Принцип прост. Допустим вы имеете одну таблицу, которая содержит данные на пользователей. Но проблема - миллионы пользователей ежедневно входят по своим аккаунтам в систему. Это создает большую загрузку сервера, не говоря о огромных размерах БД. Первое - нужно определить критерий, по которому мы будем выбирать на каком сервере содержатся данные. Мы можем сделать это по первому символу и имени пользователя. Пользователи a-j попадают в первый сервер, а k-z во второй. Это будет работать. Но скорее всего нагрузка на серверы будет не равномерной. Распространенное решение - использовать партишинг основываясь на хэше первичного ключа, в нашем случае - имени пользователя. Использование хэша позволит размещать записи более равномерно между серверами. То, что вам нужно знать про функцию хэша - это то, что она просто вычисляет номер, основанный на любом введённом значении.
Пример:
select hashtext('kristokaiv1') = 1116512480
select hashtext('kristokaiv2') = 1440348351
select hashtext('kristokaiv3') = -219299073
Объяснение, как это работает - выходит за рамки этого пособия.
Итак, допустим мы имеем 2 партиции, так что мы можем получить номер партиции основываясь на хэше имени пользователя.
Пример: partition nr = hashtext($1) & 1
&1 даст нам последний бит номера, который может быть 0 или 1. Это номер, которым мы можем выбрать партицию, на которой будут сохранены данные. Если 0 - данные попадут на партицию 0 и если 1 - на партицию 1.
select hashtext('kristokaiv1') & 1 = 0 -> partition 0
select hashtext('kristokaiv2') & 1 = 1 -> partition 1
select hashtext('kristokaiv3') & 1 = 1 -> partition 1
Как работает plproxy.
Концепция очень проста - plproxy это новый язык для запросов в PostgreSQL БД, который позволяет делать запросы к удаленным БД также как это делает dblink. Синтаксис очень прост - следующий запрос создает новую plproxy-функцию в БД, которая при запуске подключится в БД remotedb, выполнит функцию get_user_email(text) и вернет результаты.
localdb=#
CREATE FUNCTION get_user_email(username text) RETURNS text AS $$
CONNECT 'dbname=remotedb host=123.456.123.21 user=myuser';
$$ LANGUAGE plproxy;
Создадим функцию-пустышку в remotedb, которая будет отвечать на запрос
remotedb=#
create function get_user_email(text)
returns text as $$
select 'me@somewhere.com'::text;
$$ language sql;
При выполнении мы получим те же результаты, которые получаем по запросу на remotedb
localdb=#
select * from get_user_email('tere');
get_user_email
------------------
me@somewhere.com
(1 row)
Конечно это только простой пример и я вернусь к более сложному синтаксу позже. Давайте посмотрим, как установить plproxy-язык.
Установка plproxy.
Загрузить код можно с http://pgfoundry.org/projects/plproxy/ но я советую взять свежую версию из CVS (системы контроля версий).
Должен быть установлен набор разработки PostgreSLQ. Каталог, где расположена утилита конфигурации постгреса (pg_config), должен быть включен в переменную $PATH.
При этих условиях установка сводится к:
$ make
$ make install
$ make installcheck
Если у вас не получается заставить это работать - вы всегда можете попросить помощи. Финальный шаг - установить язык в БД. Это нельзя сделать как с другими языками (пользуясь утилитой createlang). Вы должны выполнить файл plproxy.sql, который создаст обработчик языка.
Файл plproxy.sql должен быть где-то в каталоге contrib.
$ psql -f /usr/local/pgsql/share/contrib/plproxy.sql queries
CREATE FUNCTION
CREATE LANGUAGE
Всё. Можно проверить установку простой plproxy-функцией (см. в синтаксических примерах).
Установка первого кластера.
Давайте создадим простой кластер, который будет состоять из 3 БД (в моем примере они все используют один и тот же вариант PostgreSQL). Одна прокси-БД вызывает запросы и две разделенные БД (партиции) с данными. Горизантальное разделение сделано на основе имени пользователя. Это часто используемый способ, т.к. большинство данных в БД - это связанные с пользователем: логин, заказы, платы, настройки...
Настройка Кластера.
Настройки БД кластеров хранятся внутри plpgsql-функций, которые вызывает плпрокси.
Существует 3 функции, которые вы должны создать для правильной конфигурации. Давайте создадим их в БД прокси.
1) plproxy.get_cluster_version(cluster_name text)
Эта функция вызывается при каждом запросе и она используется для отслеживания изменений конфигурации кластера (если возвращаемый ей номер больше, чем закешированное значение - конфигурация перезагружается). Давайте начнем с первой версии конфигурации. Пример:
CREATE OR REPLACE FUNCTION plproxy.get_cluster_version(cluster_name text) RETURNS int AS $$
BEGIN
IF cluster_name = 'queries' THEN
RETURN 1;
END IF;
END;
$$ LANGUAGE plpgsql;
2) plproxy.get_cluster_partitions(cluster_name text)
Эта функция должна возвращать строки для соединения для всех партиций в правильном порядке.
Из-за необоснованного ограничения общее кол-во должно быть кратно 2. Это необоснованное ограничение можно легко обойти, но это будет объяснено в другой раз.
CREATE OR REPLACE FUNCTION plproxy.get_cluster_partitions(cluster_name text) RETURNS SETOF text AS $$
BEGIN
IF cluster_name = 'queries' THEN
RETURN NEXT 'host=127.0.0.1 dbname=queries_0000';
RETURN NEXT 'host=127.0.0.1 dbname=queries_0001';
RETURN;
END IF;
RAISE EXCEPTION 'no such cluster: %', cluster_name;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
Если в строке соединения не указан логин для БД, будет использован текущий (CURRENT_USER). Так как плпрокси не знает ни одного пароля, разделенные БД должны разрешать соединения от БД прокси.
3)plproxy.get_cluster_config(cluster_name text)
Это эквивалент инициализационного файла. Функция должна возвращать параметры как пары ключь-значение. Все они - не обязательные, но нужно определить функцию-пустышку:
CREATE OR REPLACE FUNCTION plproxy.get_cluster_config (cluster_name text, out key text, out val text)
RETURNS SETOF record AS $$
BEGIN
RETURN;
END;
$$ LANGUAGE plpgsql;
Более подробно о параметрах и что они делают - читайте в документации plproxy.
Теперь установка завершена и можно начать "играть" с нашим новым кластером.
Давайте создадим новую таблицу для хранения имен пользователей (логинов) на обеих партициях.
#queries_0000=# CREATE TABLE users (username text PRIMARY KEY);
#queries_0001=# CREATE TABLE users (username text PRIMARY KEY);
Также нужно создать новую функцию, которая будет добавлять новые имена пользователей в таблицу:
CREATE OR REPLACE FUNCTION insert_user(i_username text) RETURNS text AS $$
BEGIN
PERFORM 1 FROM users WHERE username = i_username;
IF NOT FOUND THEN
INSERT INTO users (username) VALUES (i_username);
RETURN 'user created';
ELSE
RETURN 'user already exists';
END IF;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
Теперь давайте создадим прокси-функцию в БД прокси, которая будет вызывать запросы на партициях.
queries=#
CREATE OR REPLACE FUNCTION insert_user(i_username text) RETURNS TEXT AS $$
CLUSTER 'queries'; RUN ON hashtext(i_username);
$$ LANGUAGE plproxy;
Заполнение партиций случайными данными:
SELECT insert_user('user_number_'||generate_series::text) FROM generate_series(1,10000);
Теперь, если мы посмотрим во все БД мы увидим, что обе заполнены и заполнение почти равномерное.
queries_0001 count(*) -> 5071
queries_0000 count(*) -> 4930
Продолжение следует...
четверг, 5 марта 2009 г.
MS SQL newid() для PostgreSQL
UPDATE:
Как оказалось есть UUID. но нет функции-генератора.
Так что я поменял тип возвращаемого результата на UUID.
В данный момент работаю над переходом с MSSQL на бесплатный PostgreSQL.
Первое, на что напоролся - GUID`ов НЕТ!
Поковырял функции постгреса и написал замену:
Как оказалось есть UUID. но нет функции-генератора.
Так что я поменял тип возвращаемого результата на UUID.
В данный момент работаю над переходом с MSSQL на бесплатный PostgreSQL.
Первое, на что напоролся - GUID`ов НЕТ!
Поковырял функции постгреса и написал замену:
drop function newid();
create or replace function newid() returns uuid
as $$
DECLARE r varchar='';
chars varchar='0123456789abcdef';
i int:=1;
pos int=0;
one_char varchar(1);
begin
while i<=32 LOOP
pos=round(random()*15)+1;
one_char=cast (substr(chars,pos, 1) as varchar);
r=r||one_char;
if (length(r) in (8,13,18,23)) then r=r||'-'; end if;
i=i+1;
end LOOP;
return r;
end
$$
LANGUAGE 'plpgsql';
среда, 25 февраля 2009 г.
MSSQL - удаление большого кол-ва записей
исследование темы - удаление большого кол-ва записей из БД.
результат: скрипт для пошагового удаления.
причем удалять придется не при запросе, а в автоматическом режиме. т.е. например раз в 10 часов...
* памятка:
нельзя удалять большое кол-во записей сразу, т.к.:
1. распухнет лог транзакций
2. может не хватить свободного места из-за п.1
3. доолгооо будет удалятся
результат: скрипт для пошагового удаления.
причем удалять придется не при запросе, а в автоматическом режиме. т.е. например раз в 10 часов...
* памятка:
нельзя удалять большое кол-во записей сразу, т.к.:
1. распухнет лог транзакций
2. может не хватить свободного места из-за п.1
3. доолгооо будет удалятся
WHILE 1 = 1
BEGIN
DELETE TOP (10000) --нужно использовать top т.к. rowcount в новых версиях не будет работать для delete
FROM Table1 --таблица, откуда удалять
WHERE ToBeDeleted = 't' --флаг "для удаления"
WAITFOR DELAY '000:00:05' -- 5 задержка
IF @@ROWCOUNT = 0
BREAK
END
понедельник, 9 февраля 2009 г.
NET 3.5. Linq. Пример получения списка категорий из xml-файла системы voicecards.ru
XDocument xml = XDocument.Load(Page.MapPath("~/voicecards/xml/data.xml"));
try
{
var cards = (from x in xml.Descendants("voicecards").Elements("cards").Elements("card")
join c in xml.Descendants("voicecards").Elements("categories").Elements("category") on x.Element("catid").Value equals c.Element("catid").Value
select new
{
CardID = x.Element("cardid").Value,
CatID = int.Parse(c.Element("catid").Value),
CatName = c.Element("nameshort").Value,
CatParentID = c.Element("parentid").Value,
CatNameFull = c.Element("namefull").Value,
}
into s
group s by new { s.CatID, s.CatName, s.CatNameFull, s.CatParentID } into g
select new
{
Count=g.Count(),
g.Key.CatID,
g.Key.CatName,
g.Key.CatNameFull,
g.Key.CatParentID
}
);
}
catch { }
пятница, 30 января 2009 г.
Портфолио...
пояснение: моя часть работы - верстка (собаку съел) и кодинг.
podarki.ru
Потрачено 90% от проработанных 2-ух лет. dotNet 2.0 (3.5)/MSSQL/JS/ да много всего.
Моя работа в этом проекте - верстка и кодинг. Жуткое кол-во оптимизаций + кэширований.
Подписаться на:
Сообщения (Atom)