Pages

Sunday, November 27, 2011

Вийшов SOLR 3.5

Прес-реліз тут - http://lucene.apache.org/#27+November+2011+-+Lucene+Core+3.5.0+and+Solr+3.5.0+Available

Я б хотів відмітити тільки одне - 'Added support for Hunspell stemmer'. Тепер ви можете повнотекстовий пошук для довільної мови з коробки

Friday, July 8, 2011

Простий ETL tool

Інколи виникає потреба взяти якісь дані з однієї бази даних і перенести їх в іншу. Поки така потреба виникає лише інколи, можна цілком обходитися консольним клієнтом самої СУБД.

Проблема виникає, якщо дані потрібно переносити:

  • регулярно
  • в СУБД іншого типу (mysql -> postgresql) 
  • з не СУБД в СУБД (csv -> sql)
  • якось модифікувати дані при переносі 

Sunday, June 26, 2011

В публічному доступі існує гарна база стартапів http://www.crunchbase.com/. Вам доступна купа корисної інформації про ту чи іншу технологічну компанію.

Також існує набір скриптів, який дозволяє завантажити дані у форматі, придатному для подальшого аналізу - https://github.com/petewarden/crunchcrawl

Чим ми власне і зайнялися цієї неділі. Результати більш професійного аналізу з допомогою R будуть пізніше в блозі моєї дружини (ми вирішили провести два незалежних дослідження і пізніше порівняти висновки).

Одже, для дослідження я вибрав з повної бази в 60 тисяч проектів ті, які отримали хоч якесь фінансування, і проаналізувати саме їх. Крім того вибірку було обмежено групами, в які потрапило не меншще 50 проектів



crunchbase=# select country_code, count(*), min(amount_raised::float) / 1000 as min, max(amount_raised::float) / 1000 as max, median(amount_raised::float::int8)::int8 / 1000 as median, stddev(amount_raised::float) from org where amount_raised::float > 0 group by country_code having count(*) > 49 order by median desc;
 country_code | count | min |   max   | median |      stddev      
--------------+-------+-----+---------+--------+------------------
 CHN          |   162 |   7 |  478000 |  12000 | 54822859.7331082
 USA          |  7936 |   1 | 5620000 |   6972 | 81810808.5188822
 IND          |   162 |   6 |  300000 |   6555 | 30929815.0756823
 CHE          |    77 |  10 |  515000 |   5600 | 69345180.8354862
 CAN          |   345 | 1.2 |  350000 |   5000 | 24191815.1134509
 ISR          |   282 |  20 |  115000 |   4300 | 14798301.8257697
 IRL          |    64 |  70 |   50250 |   3900 | 8616604.81320482
 DNK          |    58 |  10 |  160400 |   3865 |  28943480.142572
 DEU          |   154 |  15 |  158700 |   3185 | 18653788.5816171
 GBR          |   526 |  10 | 1275000 |   3035 | 63979428.8180331
 FRA          |   306 |  50 |  149000 |   2935 | 12570166.9277194
 SWE          |   104 |  35 |   79960 |   2595 | 9937558.03216955
 ESP          |    83 |  15 |  218400 |   1930 | 25105973.5354224
 AUS          |    67 |   7 |   90000 |   1800 | 14347652.0292516
(14 rows)



Одже:

  • за найвищою ціною продано американський проект (5 млрд долларів - цікаво що це було??? - треба порити)
  • в загальному більші кошти отримують китайські (медіана 12 мільйонів доларів) і американські (медіана 7 мільйонів доларів) проекти 
  • в той самий час середнє відхилення (хаотичність оцінки проектів) найвища в америці.  


crunchbase=# select category_code, count(*), min(amount_raised::float) / 1000 as min, max(amount_raised::float) / 1000 as max, median(amount_raised::float::int8)::int8 / 1000 as median from org where amount_raised::float > 0 group by category_code having count(*) > 49 order by 5 desc;
  category_code   | count |  min  |    max     | median 
------------------+-------+-------+------------+--------
 semiconductor    |   335 |    35 |     540000 |  13500
 biotech          |  1300 |    10 |     598000 |  12086
 cleantech        |   516 |    10 |    1200000 |  12000
 network_hosting  |   277 |    10 |     300000 |   9400
 security         |   158 |    25 |     565000 |   8050
 hardware         |   451 |   1.1 |     409900 |   7650
 enterprise       |   429 |     5 |     217930 |   7000
 mobile           |   638 |     1 |    5620000 |   6000
 advertising      |   424 |   1.5 |     248000 |   5750
 public_relations |   372 |    10 |     283000 |   5735
 software         |  2219 |     5 |    1275000 |   5387
 consulting       |   131 |     3 |     100000 |   4575
                  |   597 | 2.667 |     260000 |   4000
 other            |   501 |     1 |     495000 |   4000
 games_video      |   580 |     5 |     519000 |   4000
 search           |   137 |     2 |     223000 |   4000
 web              |  1443 |   1.2 |    2335700 |   3000
 ecommerce        |   407 |   2.5 | 503751.458 |   2520
(18 rows)




  • Не дивно, що "піднятися" найвища імовірність на напівпровідниках і  біотехнологіях.
  • Найтяжче заробити на є-комерсі. Але саме там відбулася найдорожча продажа.
В голові крутиться кілька більш цікавих досліджень. Спробую їх реалізувати ближчим часом, якщо поточні справи не закрутять...

Wednesday, April 13, 2011

http://bradley-holt.com/2011/03/load-balancing-with-apache/

Tuesday, April 12, 2011

Saturday, April 9, 2011

Відвідав тренінг http://sonetica.ru/highload.html. Відповідно кілька нотаток з цього приводу.

Основна думка, яку намагався донести автор тренінгу - у високо навантажених проектах виникає новий клас специфічних проблем, з якими тяжко зіткнутися при розробці, наприклад, корпоративного програмного забезпечення.

Деякі з розглянутих проблем:

  • Не атомарність операцій доступу до ресурсів при високо конкурентному доступі. І, як єдина можливість ви рішення цієї проблеми, блокування та розблокування ресурсів. При цьому їх вчасне розблоковування може стати окремою великою проблемою (наприклад, якщо процес, який заблокував доступ до ресурсу не зміг успішно завершитися і зняти блок). Типовою помилкою є вважати транзакції  засобом подолання проблем конкурентного доступу. 
  • Потрібно усіляко мінімізовувати використання дискових операції. У цьому допомагають усілякі кеші та використання асинхронного підходу до операції створення і модифікації об'єктів (наприклад з використанням черги).
  • Високо навантажена система має складатися з якомога менш зв'язаних підсистем, які взаємодіють через спільну чергу повідомлень.
  • Різноманітні черги допомагають запобігати втраті даних при відмові (в результаті аварії чи високого навантаження в даний момент), наприклад, sql сервера. Не проблема, якщо користувач фейсбука не побачить своє повідомлення на власній стіні відразу після натискування кновки пост - проблема, якщо воно там взагалі ніколи не з'явиться.
  • Для того, щоб витримати різке збільшення навантаження, проект має масштабуватися лінійно. Для цього потрібна специфічна архітектура організації і збереження даних. Важливу роль відіграє правильне розбиття даних. No-sql підхід і тотальна денормалізація дозволяє побудувати систему, яка відповідає цим вимогам. Традиційні підходи (наприклад r/w split) мають обмеження (масштабуються логарифмічно) і при досягненні певно порогу навантаження перестають працювати.
  • Бажано організовувати доступ до даних за первинним ключем.
  • Дані доменну потрібно розбивати на шарди однакового розміру (наприклад по 1000 записів), для швидкого доступу потрібно зберігати метаінформацію про шард - наприклад, перший і останній id теми форума, реальна кількість тем у форумі (без врахування видалених тем); дата, автор, айді, і тема останнього повідомлення у форумі тощо.
Весь час звучала завуальвана реклама memcached/memcachedb/memcacheq, nginx, php-fpm, pinba. І усі ці інструменти дійсно варті найпильнішої уваги до себе.

Злегка була затронута тема моніторингу навантаження.

В цілому враження від тренінгу самі позитивні.

Tuesday, April 5, 2011

Search Analytics: What? Why? How?


  • Are too many users getting the dreaded “no matches” results?
  • How deep into search results do people dig?
  • Which hits are they clicking on, or what percentage of them don’t click on any hits?
  • How much do they use the “Did You Mean” or “Auto-Complete” suggestions?
Sematext at Open Source Search Conference 2011

Кажуть, що буде і у Європі...

Wednesday, March 16, 2011

Sunday, March 13, 2011

http://apps.facebook.com/newsteua/ - тестова версія фейсбук додатка від агрегатора news.te.ua

Сайти тернопільських політиків і вибори

Аналізуючи статистику агрегатора news.te.ua, можна зробити цікаві висновки:

Померли після президентських виборів
  • boleschuk.te.ua - домен "самоліквідувався"
Померли після виборів мера
  • chubak.te.ua - домен в холді
  • ratushnyak.te.ua - домен в холді
Припинив активність після виборів мера
  • roman-zastavnyy.livejournal.com - не містить жодних нових публікацій
Так і не народився
  • lylo.te.ua - домен було зареєстровано, сайт так і не появився
Я можу помилятися, але складається враження, що серйозно до інтернет-присутності наші політики не ставляться

Friday, February 25, 2011

ааааааааааа!!!!!!

http://blog.golubovsky.com/terytoriya-a-clips/

gem update system is disabled on Debian


andrew@akornilov-desktop:~$ sudo gem update --system
ERROR:  While executing gem ... (RuntimeError)
    gem update --system is disabled on Debian. RubyGems can be updated using the official Debian repositories by aptitude or apt-get.


вирішення проблеми:


sudo gem install rubygems-update
cd /var/lib/gems/1.8/bin
sudo ./update_rubygems

Monday, February 14, 2011

asterisk-ami-pgsql

http://code.google.com/p/asterisk-ami-pgsql/


Що це

Спроба надати доступ до інтерфейсу AMI  voip сервера Asterisk за допомогою мови sql використовуючи як проміжний рівень сервер  PostgreSQL

Можливості і переваги

  • Використання стандартних бібліотек для роботи з sql з довільної мови програмування
  • Використання усіх можливостей мови запитів sql для отримання доступу до внутрішньої інформації сервера voip - ви можете використовувати функції проекту як звичайні таблички сервера баз даних, здійснювати сортування, фільтрацію, проводити операції групування, операції обєднання з іншими табличками бази даних

Залежності

  • Postgresql з встановленим plpython
  • Asterisk сервер із увімкненим та налаштованим AMI інтерфейсом
  • Інсталятори пакетів Python setuptools або pip
  • Модуль pyst


Встановлення

* Завантажити код проекта
* Встановити pyst: easy_install pyst
* Виконати інсталяційний скрипт проекта: psql -U postgres asterisk -f install.sql
* Додати свій сервер та сконфігурований на ньому акаунт в табличку asterisk.managers

Приклади

Подзвонити в контакт-центр Білого дому

asterisk=# select asterisk.originate_async('localhost', 'SIP/117', '92024561111', 'default', 1);
originate_async
-----------------
t
(1 row)


Переглянути номери, які знаходяться в онлайні, обмежившись трьома

asterisk=# select * from asterisk.sippeers('localhost') where ipport <> '0' limit 3;
ipport |   status   | chanobjecttype | natsupport | objectname | realtimedevice | dynamic | acl | videosupport | channeltype |   ipaddress    |   event   
--------+------------+----------------+------------+------------+----------------+---------+-----+--------------+-------------+----------------+-----------
5060   | OK (5 ms)  | peer           | yes        | 216        | no             | yes     | no  | no           | SIP         | 10.1.10.4      | PeerEntry
2254   | OK (12 ms) | peer           | yes        | 215        | no             | yes     | no  | no           | SIP         | 10.1.10.3      | PeerEntry
2253   | OK (12 ms) | peer           | yes        | 214        | no             | yes     | no  | no           | SIP         | 10.1.10.3      | PeerEntry
(3 rows)


Monday, January 24, 2011

працюємо з тру хайлоад системами


клікнути шоб подивитися повну версію

Tuesday, January 4, 2011

Solr + довільна мова. Доповнення

Статтю http://frutik.blogspot.com/2010/12/solr.html доповнено налаштуванням фільтра стоп-слів української мови

Tomcat + Solr + UTF-8

Зіткнувся з неприємною несподіванкою. У випадку дефолтних налаштувань tomcat в centos шукати кириличні пошукові терміни неможливо :(

Рішення описане у http://wiki.apache.org/solr/SolrTomcat

Потрібно добавити URIEncoding="UTF-8" в ноду Connector port="8080" protocol="HTTP/1.1"  конфігураційного файла /etc/tomcat6/server.xml

П.С. Проблема, схоже, є тільки в редхат дистрибутивах