ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Andy Shevchenko                      2:465/192      02 Feb 2001  10:59:24
 To : All
 Subject : Re: ICQ SERVER
 -------------------------------------------------------------------------------- 
 

 Hа дворе было Sat, 16 Dec 00 16:32:54 +0200; Peter V. Chernikoff
 <Peter_V._Chernikoff@f2091.n5020.z2.fidonet.org> написал (а,о,и) по теме 'ICQ
 SERVER':
 
  AS> Есть у меня идея такой патчик написать, но... я не знаю sql. :(
  PVC>> Тогда автора пни :-).
  AS> А он уже ответил в эху :)
  PVC>  Я ru.linux практически не читаю. Что ответил-то ?
 
 Вот, что пишет по этому поводу автор.
 
 -===-
 
 Date: Thu, 1 Feb 2001 21:45:32 +1000
 From: "A.V.Shutko" <AVShutko@mail.khstu.ru>
 Message-ID: <16653658214.20010201214532@mail.khstu.ru>
 To: "Andy Shevchenko" <andy@smcl.donetsk.ua>
 
 Здравствуйте Andy,
 понедельник, 22 января 2001 г., вы писали следующее:
 
 >> бyдет   писать патчик на   mySQL, чтобы тот  поддеpживал
 >> блокиpовкy на ypовне стpок, тpанзакции и pаботy с большими объектами... :)
 
 >> Транзакции там есть. А вот зачем для icq-сервера супер-пупер
 >> навороты sql - этого мне не понять.
 
 Объясняю :)
 ----------------------
 Проблема 1:
 вот например несколько пакет-процессоров обрабатывают
 несколько пакетов одновременно от одного пользователя. Hа каждый пакет
 нужно ответить с уникальным номером последовательности seq1 и с таким
 же seq2 как и в пакете-запросе. Т.е. вся эта гопка пакет-процессоров
 ломанется в базу сначала за текущим значением seq1 а затем начнет его
 увеличивать на единицу. В итоге последовательность сбивается и клиент
 начинает игнорировать все остальные пакеты. :(
 
 MySQL решение:  оставить только один пакетный процессор или
 предусмотреть очень хитрую синхронизацию с помощью раздлеяемой памяти,
 но тогда возникнет ограничение на число online пользователей
 
 Postgres решение:
 SELECT bla-bla-bla FROM ONLINE USERS *FOR UPDATE*;
 UPDATE online_users SET servseq=servseq+1
 Первый пакет-процессор заблокирует строчку этого пользователя и после
 отправки пакета разблокирует ее, остальные в это время будут ждать.
 Такие ситуации редки и обычно наступают когда пользователь обновляет
 свои данные
 
 ----------------------
 Проблема 2:
 Пользователь вошел в систему, ему нужно знать кто из его списка в какм
 состоянии
 
 mySQL решение:
 // если в контакт листе 100 записей - 100 обращений к базе не
 // считая того, что для занесения контакт-листа в базу потребуется
 // еще 100 обращений
 insert_contact();
 for(i=0;i<contact_size; i++)
 {
    if (db_lookup(contact[i], user) != 0) send_user_online();
 }
 
 postgres-решение (субзапросы):
 insert_contact();
 pq_exec(SELECT * FROM online_users WHERE uin in (SELECT tuin FROM
 online_contacts WHERE ouin=xxxxxxx));
 
 В итоге имеем одно обращение к базе, меньший траффик с базы данных,
 оптимизированную фильтрафию, встроенную в RDBMS и существенно меньшее
 время отклика - т.е. время между коннектом и появлением первых
 online-пользователей
 ----------------------
 Проблема 3:
 Пакеты могу приходить в фрагментированном виде.
 
 mySQL решение:
 дефрагментировать пакеты в памяти - будет отжираться довольно много
 ресурсов (памяти). Дефрагментировать пакеты на диске - тогда придется
 также держать там индексный файл и писать хитрую систему сборки и
 поиска фрагментов пакетов на диске
 
 Postgres решение:
 специальная таблица с идентификаторами large-objects и сами
 large-objects. Готовность к сборке проверяется одним SQL запросом,
 найти и считать фрагменты можно тоже одним запросом - постгрес их
 заодно и отсортирует - если вдруг они в пути перепутались
 я не стал говорить про широковещательные сообщения, планируемую
 линковку серверов и прочее, но там тоже проблем хватает. Зачем мне
 лишняя головная боль, если постгрес может ее часть взять на себя ?
 ===================================================================
 И если кто напишет патчик на mySQL - я буду вполне рад :) и даже
 врисую его в проект, но перед этим подумаю - ровнее от этого он явно
 не станет. И кстати сразу замечу что ICQ Server это проще говоря
 интерфейс к базе данных с вынесенными нотификаторами. :)
 
 З.Ы. Я бы сам в фидошку запостил - но письмо кажется убил не прочитав
 - времени щас нету - последняя неделя запарки (я надеюсь). Если не
 турдно - запости ты...
 
 С уважением,
  A.V.Shutko                            mailto:AVShutko@mail.khstu.ru
 -- 
 With best regards,
 Andy Shevchenko.      mailto: andy@smcl.donetsk.ua
 
 --- slrn/0.9.6.4-bc (Linux)
  * Origin: Smile Club (2:465/192@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор