Vega никого не отключала - официальное заявление

В связи с публичными заявлениями представителей компании «Киевстар» относительно ситуации, сложившейся с блокировкой доступа абонентам «Киевстар» на сеть доступа Vega («Коммерсант»), телекоммуникационная группа Vega распространила следующее официальное заявление:

“Телекоммуникационная группа Vega не блокировала прямого канала связи между сетями доступа Vega и «Киевстар». Эту блокировку для своих абонентов осуществила компания «Киевстар».

Что касается остальных взаимосоединений сетей, через которые теоретически возможен транзит трафика между Vega и «Киевстар», то эти каналы никогда не были предназначены для транзита значительного объема трафика. Их полноценному функционированию препятствует отсутствие:

· достаточной емкости каналов для обслуживания такого объема трафика;

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

В связи со всем вышеизложенным транзит трафика компании «Киевстар» через альтернативные каналы на сеть Vega сейчас не происходит.

Кроме того, информируем, что 2.06.2010 г. Национальная комиссия по вопросам регулирования связи Украины направила на адрес ЗАО «Киевстар Дж.Ес.Ем.» письмо, в котором потребовала срочно восстановить предоставление услуг завершения трафика абонентам сети Vega и провести переговоры согласно установленной законодательством Украины процедуре.

Как ранее сообщалось, 1.06.2010 компания «Киевстар» заблокировала для своих абонентов доступ на сеть Vega, предварительно уведомив, что дальнейшее предоставление услуг будет возобновлено только после подписания договора на условиях компании «Киевстар». При этом абоненты Vegа имели возможность осуществлять звонки на сеть «Киевстар».

Сложившаяся ситуация является нарушением компанией «Киевстар» лицензионных условий, согласно которым оператор должен в обязательном порядке обеспечить маршрутизацию исходящего со своей сети трафика. Украинское телекоммуникационное законодательство в этом вопросе защищает, прежде всего, интересы абонента.

Мы неоднократно обращались к компании «Киевстар» и призывали их воздержаться от рассоединения сетей. Кроме того, мы проинформировали НКРС о сложившейся ситуации.

Напоминаем, что в течение 2010 г. продолжался переговорный процесс между Vega и «Киевстар» относительно стоимости интерконнекта. Для обеспечения полноценного и качественного предоставления услуг конечному потребителю и сохранения существующего взаимосоединения сетей по обоюдному согласию продлевалось действие договора на один календарный месяц. Ежемесячное продление старого договора и финансовых условий должно было действовать до тех пор, пока не будет достигнута договоренность, устраивающая обе стороны. 31.05.2010 истекли сроки действующего до этого момента договора о взаимосоединении сетей между компаниями, и компания «Киевстар» отказалась его продлевать на действующих условиях.

На данный момент практически со всеми остальными мобильными операторами Vega пришла к взаимовыгодным соглашениям. Из всех мобильных операторов только Киевстар в качестве аргумента в переговорах использовал противоправные действия”.

Портал meta.ua закончил 2009 год с убытком

Портал ЗАО «Мета» закончил 2009 г с чистым убытком в размере 0,9 млн грн.

2009 г интернет-компания ЗАО «Мета», которая владеет украиснким поисковиком meta.ua закончила с чистым убытком в размере 908 тыс грн /1 долл — 7,93 грн/, тогда как в 2008 г компания заработала 1,4 млн грн чистой прибыли. Об этом говорится в сообщении компании, размещенном в официальном бюллетене Государственной комисии по ценным бумагам и фондовому рынку Украины «Ценные бумаги Украины».

Дебиторская задолженность компании на конец 2009 г составила 790 тыс грн, нераспределенная прибыль – 1,18 млн грн.

Финансовые показатели ЗАО «Мета» за 2009 г планируется рассмотреть и утвердить на очередном собрании акционеров, которое состоится 6 июля 2010 г.

NoSQL - подходы к решению типичных задач

Врядли сегодня найдется тот, кто еще не слышал про key-value базы данных, или, как их называют в народе, NoSQL. Те, кто успел попробовать продукты вроде Redis, MemcacheDB и других, обнаружили некторые сложности при решении привычных задач — выборка списков и поиск.

В этой статье мы рассмотрим принципы решения типичных задач в key-value базах данных.

Основная сложность

Восновном, все key-value базы данных представляют из себя распределенные хеш-таблицы. Это самая сильная их сторона, т.к. предоставляет высокую производительность и крайне упрощает масштабирование. Тем не менее, это свойство всплывает на поверхность, когда Вам необходимо работать со списками. В MySQL следующие задачи решаются в два счета:

• Выбрать 10 последних пользователей


• Выбрать Самые популярные посты в блоге


• Найти продукты, для которых оставлено более 3х комментариев


• Полнотекстовый поиск


• Поиск по любому свойству (найти пользователя, email которого такой-то)

Но в key-value подобные задачи вызывают удивление и большие трудности. В двух словах, key-value базы данных совсем не предназначены для таких задач. Но это только на первый взгляд, ведь формулировать задачи можно по-разному. Стратегия решения будет зависеть от конкретной ситуации.

И так, по порядку:

Поиск по ключу

Существует класс задач, когда Вам необходимо делать выборку одного объекта не по первичному, а вторичному ключу (например, поиск пользователя по email’у, поиск автора по никнейму т.п.). Принцип решения этой задачи следующий: после создания нового объекта, Вам необходимо создать ссылки на его первичный ключ для всех его свойств, по которым придется делать выборку. Например мы создаем пользователя:

user_134: {
  name: Den,
  email: golotyuk@gmail.com
}

И дублируем ключ email:

user_email_golotyuk@gmail.com: {
  id: 134
}

Теперь, Вы сможете сделать выборку данных пользователя по его почтовому адресу в два этапа.

Использование РСУБД

Если Вам нужен MySQL — используйте его, не стреляйте по воробьям их танка

Существует класс задач, для которых можно и нужно использовать РСУБД, такие как MySQL и Postgres. Если Вам необходимо делать выборки списков с фильтрами и сортировками, то Вам следует использовать более подходящую для этого РСУБД. Хороший пример — это посты в блоге. (выборки, которые скорее всего нужно будет делать — самые новые, самые популярные, самые комментируемые записи и т.п.).

Подход довольно простой, но на практике очень часто задачи сильно переплетены, и в итоге Вы можете прийти к тому, что РСУБД возьмет все задачи обратно на себя. В этом случае следует подумать о гибридном решении:

Гибридное решение — дополнительная РСУБД

Это решение представляет из себя смесь key-value и РСУБД. Все данные Вы храните в key-value, но те свойства, по которым понадобиться делать агрегатные выборки дублируете в РСУБД (с указателем на ключ). Т.о. Вы сохраните производительность key-value базы данных и сможете решить свою задачу. Сложность тут заключается в том, что Вам придется следить за синхронизацией данных в обоих базах данных, что может сильно усложнить логику приложения.

Полнотекстовый поиск и выборки с задержками

Одна из частых задач — полнотекстовый поиск. Существуют отличные решения — Sphinxsearch, Solr и другие. К сожалению, ни одно из них еще не поддерживает индексацию key-value баз данных, но зато все предоставляют интерфейсы для ручной индексации. Вам нужно будет только описать реализацию для конкретного набора данных (например, с помощью XmlPipe в Sphinx’e).

Наряду с полнотекстовым поиском часто стоят и задачи, связанные с агрегатными выборками, которые не критичны к текущему состоянию данных. Например, когда Вы строите рейтинг пользователей (или постов в блоге, или продуктов в магазине или …), Вы можете спокойно использовать данные по состоянию на прошлый час(день/неделю/…). В качестве решения Вы можете использовать полнотекстовые серверы по их непрямому назначению. Многие из них поддерживают разнообразные фильтры и сортировки, которых достаточно для решения 90% задач подобного рода.

Распределенные выборки

Некоторые key-value базы данных позволяют делать выборки списков встроенными средствами. Масштабирование этого решения будет выглядеть как запросы ко всем узлам сети и агрегирование результатов на бекенде. В крупных масштабах это может быть очень затратная операция, поэтому это решени слеудет оптимизировать. Во многих случаях Вы можете обойтись без запросов ко всем узлам, а сделать выборку только на одном из них (например — выбрать случайное фото).

Что еще сюда можно добавить?

Related posts:

1. Key=value (ключ=значение) базы данных

Полнотекстовый поиск в MongoDB используя Sphinx

Многие из тех, кто успел попробовать MongoDB в действии, столкнулись с трудностями с полнотекстовым поиском. Встроенный механизм полнотекстового поиска в MongoDB (его так можно назвать с большой натяжкой) не пригоден для реальных потребностей.

Основная проблема заключается в том, что sphinx не позволяет использовать буквенно-цифровые значения в качестве ID документов. Есть несколько вариантов решения этой проблемы.

Строим индекс с помощью xmlpipe

Поскольку в Sphinx пока нет реализации источника данных для mongo, то придется использовать XMLpipe для индексации:

source src_test {
    type = xmlpipe
    xmlpipe_command = php /home/golotyuk/www/mongosphinx/index.php
}

index test {
        morphology              = stem_enru
        charset_type            = utf-8
        source                  = src_test
        path                    = /var/lib/sphinxsearch/data/test
}

Реализация XML генератора может быть приблизительно такая:

<?='<?xml version="1.0" encoding="utf-8"?><sphinx:docset>'?>

<sphinx:schema>
<sphinx:field name="content"/>
</sphinx:schema>

<?

$m = new Mongo();
$c = $m->test->documents;
$list = $c->find();

?>

<? foreach ( $list as $document ) { ?>
<sphinx:document id="<?=$document['numeric_id']?>">
<content><![CDATA[[<?=$document['text']?>]]></content>
</sphinx:document>
<? } ?>

</sphinx:docset>

Все предельно просто кроме одной проблемы — ID mongo документа представлен в буквенно-цифровом виде, чего не понимает сфинкс. Есть несколько подходов:

Решение проблемы с ID документа

Пользовательский ID

Первый вариант — хранить в каждом mongo-документе пользовательский (сгенерированный руками) цифровой ID отдельным свойством:

{
	"_id" : ObjectId("4bf2c7f38ead0e0d05070000"),
	"sid" : 7,
	"text" : "Много текста"
}

В этом случае свойство sid будет использоваться для индексации в качестве ID документа (в примере выше атрибут называется “numeric_id”).

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

В качестве альтернативного решения можно использовать таблицы соответствий ID документа Mongo и ID документа Sphinx (например в MySQL). В этом случае не нужно будет руками реализовывать механизм автоинкремента, но придется использовать дополнительную СУБД.

Выборка ID, как атрибута

ID mongo-документа можно выбирать как атрибут при индексации. Это наиболее верное решение, но учитывая, что атрибут строчный, понадобится обновиться до версии 0.9.10 (на этот момент эта версия еще не в релизе).

В этом случае Вам просто придется генерировать уникальные ID для сфинкса (которые будут фактически бесполезными для Вас — их можно генерировать на этапе индексации), а mongo ID доставать как свойство. Схема индекса будет следующая:

<sphinx:schema>
<sphinx:field name="content"/>
<sphinx:attr name="_id" type="string"/>
</sphinx:schema>

Как видно, id mongo-документа описан как строчный атрибут. Для генерации id документа sphinx можно использовать простой инкремент, например:

<? $i = 0; foreach ( $list as $document ) { ?>
<sphinx:document id="<?=$i + 1?>">
<content><![CDATA[[<?=$document['text']?>]]></content>
<_id><?=$document['_id']?></_id>
</sphinx:document>
<? } ?>

В результате sphinx будет возвращать атрибут “_id”, в котором будет находится идентификатор документа Mongo.

Related posts:

1. Дельта индекс в Sphinx
2. Solr — полнотекстовый поиск от Apache (на основе Lucene)
3. Sphinxsearch — объединение индексов (index merging)

В Украине - еще одна WiMax-сеть

Вслед за FreshTel еще один оператор запустил коммерческую эксплуатацию WiMax-сеть, и снова в Киеве. В регионы надо идти, товарищи!

Сенсорный LG Cookie Fresh - уже в Украине

Компания LG Electronics представляет в Украине новый сенсорный телефон LG Cookie Fresh (GS290), воплотивший в себе лучшие черты первого телефона в линейке Cookie, легендарной модели KP500. Обладая всеми возможностями своего популярного предшественника, новый Cookie предлагает пользователю еще больше развлекательных функций и интерактивных возможностей.

Появление новой модели в линейке Cookie стало лучшим подтверждением успеха оригинального телефона Cookie КР500, который заслужил любовь пользователей благодаря сбалансированной функциональности, приятному дизайну и доступной цене. Напомним, что всего за 13 месяцев с начала продаж KP500, во всем мире было реализовано свыше 10 миллионов моделей. Таким образом, первый Cookie стал самым быстро продаваемым телефоном с полностью сенсорным экраном за всю историю LG и одним из самых успешных телефонов компании на украинском рынке. Начиная с апреля 2009 года, в Украине было продано более 50 тысяч экземпляров LG KP500.

Продолжая линейку Cookie, компания LG Electronics представляет в Украине новую модель — LG Cookie Fresh (GS290). Как и его успешный предшественник, новинка удобна в использовании и оснащена 3-дюймовым сенсорным дисплеем, при этом может похвастаться удобным и быстрым графическим интерфейсом и мгновенным доступом к социальным сетям, что является немаловажным критерием при выбоер телефона в современном мире. Классический дизайн новинки делает ее уместной для использования как мужчинами, так и женщинами, а богатый выбор расцветок позволит каждому выбрать себе телефон по вкусу.

Большой 3-дюймовый сенсорный экран GS290 обладает хорошим откликом, предлагая простой и удобный доступ к функциям телефона с помощью уникального приложения Live Square и обновленного интерфейса А-класса, который обеспечивает мгновенное отрабатывание нажатий, превращая работу с телефоном в сплошное удовольствие. Высокая чувствительность экрана позволяет распознавать даже самые легкие нажатия, что можно удобно использовать при просматривании больших объемов текста или во время навигиции по меню (сильные нажатия ускоряют пролистывание, а более слабые замедляют).

LG Cookie Fresh оснащен и множеством интересных развлекательных функций. Любители творческих решений наверняка оценят функцию рукописного ввода и возможность рисовать на дисплее телефона одним прикосновением, а эстетам особенно понравятся анимированный пользовательский интерфейс и красивые темы оформления. Меломанов порадует наличие 3,5-миллиметрового разъема, который позволяет подключать к телефону стандартные наушники и наслаждаться любимыми музыкальными композициями.

Кроме того, ориентированный на общение в социальных сетях GS290 имеет в своем распоряжении целый арсенал сетевых функций. Так, нажатие на ярлык с названием Facebook и Twitter, а также популярных среди украинских пользователей «Одноклассники» и «Вконтакте» мгновенно переносит пользователя на соответствующий ресурс, а функция SNS обновляеть эти страницы в режиме реального времени. Пакет сервисов «Яндекс» обеспечивает удобный доступ к следующим услугам: «Поиск», «Погода», «Новости», а также приложениям «Я.Онлайн» и «Яндекс.Карты». Для удобства пользователей в телефоне предустановлены русско-английский словарь и программа для просмотра офисных документов.

В продаже в Украине телефон LG Cookie Fresh GS290 появится  к концу мая и будет доступен в широком ассортименте цветов: черный, винно-красный, розовый, сиреневый, серебристый. Кроме того, в сетях магазинов «Евросеть» можно будет приобрести два эксклюзивных цветовых варианта этого телефона — бело-сиреневый и серебристо-синий.

Читайте также обзор LG Cookie Fresh

Технические характеристики

Сеть	EDGE
Параметры сети	GSM 850/900/1800/1900
Батарея	900 мАч
Габариты	108х53х12,5 мм
Экран	3 дюйма, WQVGA (240×400), 262 тыс.цветов
Камера	2 Мп, фиксированный фокус
Память	32 МБ, расширяется с помощью MicroSD до 16 ГБ
Bluetooth	2.1+EDR
USB	2.0 Micro USB
Аудиокодеки	MP3, AAC, AAC+, WMA
Видеокодеки	MPEG4, H.263
Браузер	WAP 2.0
Java 2.0	2.1
Сообщения	SMS, MMS, E-mail
Чипсет	S-Gold 3
Другое	FM-радио с функцией RDS, Запись радио «на лету» Возможность прослушивания радио без гарнитуры

Харьков - срочно нужен Flash Developer

В дружный коллектив ИТ-компании требуется Flash Developer. Требуется уверенное знание и опыт работы с Adobe Flash (Action Script 2.0, 3.0 ). Желательно знание английского языка. Приветствуется умение работать в команде, организованность и хорошее настроение.

Наша фирма занимается разработкой игр. Размер зарплаты -- по результатам собеседования (опыт, знания и умения). Никто обиженным не останется. Условия работы хорошие, практикуется система поощрений — так что уровень ЗП полностью в ваших руках. Ждем резюме и портфолио на почту miroshnichenko(sobaka)web-solution.com.ua с указанием в теме письма «Flash developer»!

Огромная просьба: если у вас есть знакомые флешисты в Харькове, которые хотят или собираются менять место работы (или просто хотят развиваться дальше — касательно ЗП и условий) — буду очень признательна, если дадите ссылку на нашу вакансию. Заранее огромное спасибо!

контакты: skype: anna-miroshnichenko, icq: 437304035