Pages

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. І усі ці інструменти дійсно варті найпильнішої уваги до себе.

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

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