Pull to refresh
152
0
Андрей Смирнов @smira

User

Send message

MDC: beta-релиз мультипротокольного мессенджера под Linux!

Reading time3 min
Views1.7K
Совсем недавно на Хабре мы рассказывали о beta-релизе нового мультипротокольного мессенджера MDC под ОС Windows от компании Netstream.

Мы получили от Вас больше сотни отзывов и предложений, исправили некоторое количество багов и, самое главное, подготовили beta-релиз под Linux (32/64), который и хотим сегодня Вам представить.


Что же нового?

Кэширование и memcached

Reading time7 min
Views87K

Этим постом хочу открыть небольшую серию постов по материалам доклада на HighLoad++-2008. Впоследствии весь текст будет опубликован в виде одной большой PDF-ки.



Введение


Для начала, о названии серии постов: посты будут и о кэшировании в Web’е (в высоконагруженных Web-проектах), и о применении memcached для кэширования, и о других применениях memcached в Web-проектах. То есть все три составляющие названия в различных комбинациях будут освещены в этой серии постов.
Читать дальше →

MDC: beta-релиз нового мультипротокольного мессенджера

Reading time3 min
Views3.1K
Сегодня я расскажу о MDC — новом проекте компании NetStream. MDC – мультипротокольный клиент обмена сообщениями с поддержкой операционных систем Windows, Linux, MacOS X и протоколов ICQ, Mail.Agent, Jabber, AOL (постепенно мы будем расширять список протоколов).

Что за велосипед они изобрели?

Лог комита: зачем он нужен на самом деле?

Reading time4 min
Views5.3K
Разработчики уже давно привыкли пользоваться системами контроля версий. Для кого-то это является естественным переходом, кто-то воспринимает сначала систему контроля версий как некоторое дополнительное усложнение своей работы, но работа над проектом в команде невозможна без этого инструмента.

Очень часто переход от мышления «я сохранил файл — код зафиксирован» к мышлению «я сделал комит — код зафиксирован» натыкается на то, что процесс комита требует написания лога комита. Первое решение — оставить лог пустым или написать что-то из:

  • «фикс бага»;
  • «закомитил всё, что сделал»;
  • «тестовый комит»;
  • «исправил опечатку»;
  • и т.п.

Почему это плохо?

Индексы и селективность (PostgreSQL)

Reading time1 min
Views34K
Индекс по полю в БД потенциально может ускорить SELECT операцию с условием по данному полю, может ускорить запрос вида: ORDER BY поле LIMIT 20, но индекс существенно замедляет операции изменения таблицы и т.п.

Когда нужен индекс, когда он поможет и будет использован при SELECTах? Всё зависит от селективности индекса, т.е. от кол-ва строк, которые мы получим если зададим условие:
проиндексированное_поле = значение


Отличный кандидат для индексирования — селективность 1, т.е. уникальный индекс (например, id), когда по указанному значению мы найдем максимум одну запись.

Рассмотрим в качестве примера таблицу пользователей с полями информации о регионе: страна (country_id) и город (city_id). Хорошо, когда селективность составляет < 5% (например, поле city_id у пользователя). При этом PostgreSQL умён, он считает не селективность “вообще” по полю, а селективность в виде гистограммы по отдельным значениям поля. Т.е. если мы задаем условие вида

страна = Россия


то получим 10% записей из БД, а если условие

страна = Уругвай


то получим 2 записи, и это PostgreSQL понимает. (Конечно, здесь мы предлполагаем, что пользователей из Уругвая на нашем сервере гораздо меньше, чем пользователей из России).

Так вот, если селективность плохая (получаем много записей), PostgreSQL предпочтёт выполнить полное сканирование БД, не используя индекс. И такой индекс только мешает.

P.S. Кросс-пост из моего блога
2

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity