+7 499 990-10-21

А чем обусловлен выбор БД?

А чем обусловлен выбор БД?

Сообщение Sergey78 » 29 ноя 2010, 12:48

Добрый день.
Расскажите пожалуйста, а почему в качестве БД был выбран именно Postgresql ? Насколько я могу представить (извиняюсь, если ошибаюсь), БД нужна лишь для хранения справочника товаров и транзакций. Почему бы не использовать например SQLite? Postgres все же достаточно тяжеловесный с "взрослым" подходом, SQLite гораздо "легче".

Заодно, чтоб не поднимать еще одну тему, хотел поинтересоваться, как загружается справочник товаров. Допустим первый раз я выгружаю всю номенклатуру (1С 7.7). Демон достаточно долго загружает ее в кассу. Был допустим приход, надо загрузить новые позиции. Достаточно выгрузить только те позиции, что в документе (это не сложно сделать, чуть изменив вашу обработку)? Они добавятся в справочник товаров в БД? А как реализовано удаление старых позиций?
И что будет, если я повторно выгружу всю базу номенклатуры?
Можно было бы конечно посмотреть внутрь БД, но я к сожалению не имею опыта с postgres. По каким полям строится индекс? По внутреннему коду?
Sergey78
 
Постов: 76
Зарегистрирован: 26 ноя 2010, 13:47

Re: А чем обусловлен выбор БД?

Сообщение BigAndy » 29 ноя 2010, 13:07

Postgres все же достаточно тяжеловесный с "взрослым" подходом, SQLite гораздо "легче"

ЖЖете.
1) SQLite ну ни разу не имеет клиент-серверной архитектуры.
2) Наши корпоративные нужды (включая postfix и авторизацию) обеспечивает vds cel400/64 Мб. Утилизация никогда более 30% ( в случае запуска пакетной обработки) не достигает. При этом обеспечивает еще imap/pop3/spamassasin/web сервисы

По каким полям строится индекс? По внутреннему коду?

Заведите себе pgadmin и всё увидете.
BigAndy
 
Постов: 461
Зарегистрирован: 29 ноя 2009, 17:11

Re: А чем обусловлен выбор БД?

Сообщение Sergey78 » 29 ноя 2010, 13:40

BigAndy писал(а):Postgres все же достаточно тяжеловесный с "взрослым" подходом, SQLite гораздо "легче"
ЖЖете.
1) SQLite ну ни разу не имеет клиент-серверной архитектуры.

А она нужна в данном случае? Я только начал разбираться с программой и возможно пока чего-то не понимаю.
Мне как раз кажется, что удобнее иметь максимально урезанный дистрибутив с необходимым минимумом.
У меня на рабочих местах используются тонкие клиенты, с бездисковой загрузкой по сети. Работают через RDP, в качестве клиента - Thinstation. Образ который раздается по сети, это 1.5мб ядро и 30 мб initrd, который в память разворачивается. Там внутри Х-ы, icewm, samba, freerdp и куча драйверов и модулей. Это не совсем правильный подход, если следовать рекомендациям авторов Thinstation, образ был бы меньше. Распакованный размер я не мерил, но на 128МБ (диска там нет, свопить некуда) все работает. До кассового узла там не хватает только самой программы (еще 1.5 мб) и БД.
Именно поэтому и подумал про SQLite. У меня сейчас на виртуалке файл good.txt размером 4.7мб загружался минут 10. Память оно особо не ело (занято было около 50 мб), зато процессор (одно ядро от ноутбучного i5) был загружен на 100% процессом postgres.
SQLite хранит базу в обычном файле. Соответственно базу товаров можно было бы сформировать на сервере и уже готовый файл залить на кассу. Время обновления - только закрыть соединение с одним файлом и открыть с новым. При этом касса остается автономной, она не зависит от других серверов в сети и может работать одна.

Я не пробовал реально работать с SQLite, поэтому это лишь мое предположение. В любом случае, разработчикам виднее, что и как делать.

BigAndy писал(а):2) Наши корпоративные нужды (включая postfix и авторизацию) обеспечивает vds cel400/64 Мб. Утилизация никогда более 30% ( в случае запуска пакетной обработки) не достигает. При этом обеспечивает еще imap/pop3/spamassasin/web сервисы
Заведите себе pgadmin и всё увидете.


Причем тут касса и почтовый сервер? Не знаю как у вас настроен spamassasin, у меня при не самом большом потоке почты 64МБ не хватало. Почтовик правда exim был, но это по сути не важно.
Sergey78
 
Постов: 76
Зарегистрирован: 26 ноя 2010, 13:47

Re: А чем обусловлен выбор БД?

Сообщение Alexander » 29 ноя 2010, 14:26

Sergey78 писал(а):Расскажите пожалуйста, а почему в качестве БД был выбран именно Postgresql ?

Выбран был во-первых из-за лицензии, во-вторых как раз из-за потенциала использования. Клиент-серверная архитектура нужна, например, для реализации режима "единые остатки на все кассы локальной сети". Также возможность сетевого администрирования, мониторинга и т.п.
P.S. К тому же наш собственный опыт (с 1998 г.) сопровождения различных РМК для ОС Windows с файловыми БД показывает, что с ними периодически возникают различные проблемы.

Sergey78 писал(а): как загружается справочник товаров. Был допустим приход, надо загрузить новые позиции. Достаточно выгрузить только те позиции, что в документе (это не сложно сделать, чуть изменив вашу обработку)? Они добавятся в справочник товаров в БД? А как реализовано удаление старых позиций? И что будет, если я повторно выгружу всю базу номенклатуры?

В протоколе есть три базовые команды (будем рассматривать более "продвинутый" протокол "АТОЛ/Frontol"):
- $$$DELETEALLWARES
- $$$REPLACEQUANTITY
- $$$ADDQUANTITY
Первая команда очищает справочник товаров.
Если этой команды в файле загрузки нет, тогда текущие остатки товаров будут:
- замещаться (вторая команда) или
- добавляться (третья команда)
Таким образом идеальная схема работы товароучётки была бы такая:
- прогружаем все текущие остатки ($$$DELETEALLWARES, затем $$$REPLACEQUANTITY)
- когда необходимо добавить остатки по каким-то товарам, формируем файл с командой $$$ADDQUANTITY (например, на основании документа "Накладная перемещения на склад торгового зала")
- когда необходимо перезагрузить всю БД работаем по первому варианту.
Alexander
 
Постов: 4959
Зарегистрирован: 16 авг 2009, 23:34
Откуда: Техподдержка ГК ДЭНСИ

Re: А чем обусловлен выбор БД?

Сообщение BigAndy » 29 ноя 2010, 15:06

А она нужна в данном случае?
А вы собираетесь LinCah и Transactios хранить на локальных станциях?

Мне как раз кажется, что удобнее иметь максимально урезанный дистрибутив с необходимым минимумом.

Ну, собственно, мы так и поступили. Кастрировали центос по самое некуда. Оставили только иксы на ФРЕЙМБУФЕРЕ.


У меня на рабочих местах используются тонкие клиенты, с бездисковой загрузкой по сети.

Совершенно аналогично. Только LTSP и SSH - для удаленных машин(они не бездисковые).
Там внутри Х-ы, icewm, samba, freerdp и куча драйверов и модулей.
А это ***мо зачем? и без него все работает. Вы линукс или маздай поднимаете?

Это не совсем правильный подход, если следовать рекомендациям авторов Thinstation, образ был бы меньше.
-------------------
Именно поэтому и подумал про SQLite.

Это с какого такого перепою постоянно пухнущий sqlite, данные из которого вам придется либо грузить в RAM, синхронизировать его, либо монтировать и гонять туда-сюда огромное количество паразитных данных по сети. будет уменьшать загрузочный образ? Вполне достаточно одной RDBMS и локальный libpq/psql.


У меня сейчас на виртуалке файл good.txt размером 4.7мб загружался минут 10. Память оно особо не ело (занято было около 50 мб), зато процессор (одно ядро от ноутбучного i5) был загружен на 100% процессом postgres.

Не знаю как у вас настроен spamassasin, у меня при не самом большом потоке почты 64МБ не хватало. Почтовик правда exim был, но это по сути не важно.


Не, ну кто может запретить загружать его на 200%?
А вот у меня так:
Код: Выделить всё
[andrew@corporate ~]$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz
stepping        : 10
cpu MHz         : 297.857
cache size      : 6144 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
bogomips        : 5000.09

[andrew@corporate ~]$ free
             total       used       free     shared    buffers     cached
Mem:         65536      65536          0          0          0          0
-/+ buffers/cache:      65536          0
Swap:            0          0          0
[andrew@corporate ~]$ ps xau
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.8   2064   580 ?        Ss   Oct31   0:04 init [3]     
dovecot   3787  0.0  2.7   4888  1828 ?        S    13:22   0:00 pop3-login
dovecot   3788  0.0  2.7   4888  1828 ?        S    13:22   0:00 pop3-login
root      5635  0.0 47.8  36844 31380 ?        Ss   12:01   0:00 /usr/bin/spamd -d -c -m5 -H -r /var/run/spamd.pid
root      5750  0.1 58.4  43764 38328 ?        S    12:01   0:08 spamd child
root      5752  0.0 51.5  39308 33768 ?        S    12:01   0:00 spamd child
postfix  11586  0.0  2.9   8460  1952 ?        S    11:53   0:00 anvil -l -t unix -u
1001     11707  0.0  2.6   3316  1716 ?        S    Nov27   0:00 imap
postfix  20264  0.0  4.9   8892  3276 ?        S    13:29   0:00 smtpd -n smtp -t inet -u -o stress  -s 2 -o smtpd_sasl_auth_enable yes
postfix  22348  0.0  2.9   8472  1924 ?        S    13:09   0:00 pickup -l -t fifo -u
root     24063  0.0  4.2   9960  2760 ?        Ss   13:30   0:00 sshd: andrew [priv]
dovecot  24265  0.0  2.7   4888  1828 ?        S    13:30   0:00 pop3-login
andrew   25716  0.0  2.4   9960  1624 ?        S    13:30   0:00 sshd: andrew@pts/0
andrew   25720  0.0  2.4   5556  1600 pts/0    Ss   13:30   0:00 -bash
postfix  26266  0.0  3.2   8656  2140 ?        S    13:31   0:00 smtp -t unix -u
andrew   26417  0.0  1.4   5116   924 pts/0    R+   13:31   0:00 ps xau
root     28314  0.0  0.4   2148   324 ?        S<s  Oct31   0:00 /sbin/udevd -d
1004     28409  0.0  1.9   2852  1268 ?        S    01:01   0:00 imap
1000     28410  0.0  2.2   2892  1480 ?        S    01:01   0:00 imap
1001     28411  0.0  2.5   3328  1680 ?        S    01:01   0:00 imap
dovecot  28428  0.0  2.7   4896  1832 ?        S    01:01   0:00 imap-login
dovecot  28430  0.0  2.7   4896  1832 ?        S    01:01   0:00 imap-login
dovecot  28431  0.0  2.7   4896  1832 ?        S    01:01   0:00 imap-login
dovecot  28432  0.0  2.7   4896  1828 ?        S    01:01   0:00 imap-login
dovecot  28433  0.0  2.7   4896  1832 ?        S    01:01   0:00 imap-login
root     29846  0.0  0.8   1720   564 ?        Ss   Oct31   3:51 syslogd -m 0
named    29912  0.0  6.1  40440  4016 ?        Ssl  Oct31   2:34 /usr/sbin/named -u named -t /var/named/chroot
root     29957  0.0  1.1   7124   768 ?        Ss   Oct31   0:08 /usr/sbin/sshd
postgres 30031  0.0  2.4  46732  1616 ?        S    Oct31   0:00 /usr/bin/postmaster -p 5432 -D /var/lib/pgsql/data
root     30165  0.0  0.9   1892   608 ?        Ss   Oct31   0:20 /usr/sbin/dovecot
root     30168  0.0  2.7   8320  1784 ?        S    Oct31   0:07 dovecot-auth
root     30719  0.0  2.4   8396  1580 ?        Ss   Oct31   0:26 /usr/libexec/postfix/master
postfix  31762  0.0  2.6   8536  1704 ?        S    Oct31   0:10 qmgr -l -t fifo -u
postfix  31820  0.0  2.5   8468  1644 ?        S    Oct31   0:01 tlsmgr -l -t unix -u
root     31822  0.0  0.6   7812   420 ?        Ss   Oct31   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    31823  0.0  1.4   8008   920 ?        S    Oct31   0:01 nginx: worker process                   
root     31836  0.0  1.4   6152   964 ?        Ss   Oct31   0:00 crond
root     31917  0.0  0.4  11048   308 ?        S    Oct31   0:00 python /usr/sbin/pysieved -c /etc/pysieved.ini
postgres 32012  0.0  0.6  14900   436 ?        Ss   Oct31   0:11 postgres: logger process                         
postgres 32016  0.0  0.9  46716   608 ?        Ss   Oct31   0:58 postgres: writer process                         
postgres 32017  0.0  0.7  46716   460 ?        Ss   Oct31   1:00 postgres: wal writer process                     
postgres 32018  0.0  0.8  46732   588 ?        Ss   Oct31   0:14 postgres: autovacuum launcher process             
postgres 32019  0.0  0.6  14900   440 ?        Ss   Oct31   0:07 postgres: stats collector process       

Ибо линукс. Виртуалка XEN. Как видите, выделены ресурсы cel 400/64МБ.


SQLite хранит базу в обычном файле. Соответственно базу товаров можно было бы сформировать на сервере и уже готовый файл залить на кассу.

А в Client-server вам даже ничего заливать не надо до исполнения запроса. Какой смысл полностью гонять данные туда-обратно?
Время обновления - только закрыть соединение с одним файлом и открыть с новым.

Ахха. Забыли посчитать время передачи всей таблицы на сторону клиетне, время выборки (причем без индексов), время модификации данных, время пересылки полностью модифицированного файла на сторону сервера, время записи на носитель... Вот прямо адынэс7.7 такой получится
При этом касса остается автономной, она не зависит от других серверов в сети и может работать одна.

А она и так зависит от одного сервера.

Причем тут касса и почтовый сервер?

При том, что данные централизованно хранятся на этом сервере. Плюс этот же постгрес обслуживает авторизацию и почту (хранит ее там). Ибо pam_postgresql
BigAndy
 
Постов: 461
Зарегистрирован: 29 ноя 2009, 17:11

Re: А чем обусловлен выбор БД?

Сообщение Sergey78 » 29 ноя 2010, 16:12

BigAndy писал(а):А вы собираетесь LinCah и Transactios хранить на локальных станциях?


Да. Чтоб не было ситуации, что на сервере какие-то работы и касса не работает. Если для работы кассы (у меня она пока одна) нужно два компьютера, вероятность что хоть один их них выйдет из строя вдвое выше. Поэтому я и хочу хранить базу postgres-а на кассе, выгружая оттуда продажи.

BigAndy писал(а):А это ***мо зачем? и без него все работает. Вы линукс или маздай поднимаете?

Которое именно? Товароучет в 1С 7.7, которая на терминальном сервере. Пользователи по rdp туда подключаются.

BigAndy писал(а):Это с какого такого перепою постоянно пухнущий sqlite, данные из которого вам придется либо грузить в RAM, синхронизировать его, либо монтировать и гонять туда-сюда огромное количество паразитных данных по сети. будет уменьшать загрузочный образ? Вполне достаточно одной RDBMS и локальный libpq/psql.

В случае с sqlite наличие диска конечно нужно.

BigAndy писал(а):Ахха. Забыли посчитать время передачи всей таблицы на сторону клиетне, время выборки (причем без индексов), время модификации данных, время пересылки полностью модифицированного файла на сторону сервера, время записи на носитель... Вот прямо адынэс7.7 такой получится

Давайте разделим базу с транзакциями и базу с товаром.
Базу с транзакциями мне достаточно раз в сутки перегонять с кассы на сервер (скажем при закрытии смены). Размер который переписывается по сети и сколько это будет обрабатывать сервер, вообщем-то не важно. Касса уже пишет в другой файл и ей это все равно.
Базу со справочником товаров мне как раз нужно подгружать в течении дня. Либо целиком, либо только изменения. Формировать ее будет сервер (тут не сильно важно сколько это по времени, 5 минут или 10), и потом готовую писать на кассу. Как только есть новая база со справочником товаров, отключились от старой, подключились к новой.

При этом касса остается автономной, она не зависит от других серверов в сети и может работать одна.
А она и так зависит от одного сервера.

Не работает сервер - не работает касса. Меня это не устраивает. В моем случае возможен вариант, что выключили электричество на вводе с которого запитан сервер, а касса в торговом зале работает.


Я не агитирую за SQLite, мне просто было интересно почему именно так. В вашем случае (судя по написанному в посте про установку на убунту), действительно целесообразнее иметь централизованный сервер. Мне выгоднее (надежнее) иметь автономную кассу.
Sergey78
 
Постов: 76
Зарегистрирован: 26 ноя 2010, 13:47

Re: А чем обусловлен выбор БД?

Сообщение BigAndy » 29 ноя 2010, 19:08

Sergey78 писал(а):
Не работает сервер - не работает касса. Меня это не устраивает. .

А она и так не работает, поскольку у вас касса-thinclient по вашему же условию. Кроме того, это у вас одна касса. У меня уже пять. И что? на каждой содержать свою БД?

В моем случае возможен вариант, что выключили электричество на вводе с которого запитан сервер, а касса в торговом зале работает

В моем случае то происходит по нескольку раз в неделю. Для этого существует резервирование питания.
Мне выгоднее (надежнее) иметь автономную кассу.

Кроме того, кто вам запрещает воткнуть на один сервер postgres и Денси:касса, то есть дефолтная установка? Минимально испытанная конфигурация железа - PIII-800/128 /centos /nx440. Не используем только потому, что железу более десяти лет.
BigAndy
 
Постов: 461
Зарегистрирован: 29 ноя 2009, 17:11


Вернуться в Ваши предложения

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 12


cron

Кто сейчас на конференции

Сейчас посетителей на конференции: 12, из них зарегистрированных: 0, скрытых: 0 и гостей: 12 (основано на активности пользователей за последние 5 минут)
Больше всего посетителей (170) здесь было 16 май 2020, 01:50

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 12