Артем Комаров

BigData не очень то и связана со структурами данных - в основном это разнообразные пространственные структуры, скорее больше связана с алгоритмами NLP, классификации и машинного обучения.

В первую очередь нужно выбрать средство обработки и хранения.
В случае с Java это HBase Cassandra
HBase - когда пишется в базу очень много, и большинство индексов "самодельные".
Cassandra - когда соотношение чтения / записи 4:3, так как в Cassandra уже есть средства колоночной индексации.

В случае с реальным высоконагрузом это ScyllaDB - обладает теми же особенностями что и HBase, но С++11 и Share-nothing approach и от того в 6-7 раз шустрее.

Для БД до 200Гб хватит банального MySQL'я c R-tree индексом и Engine Archive.
Вот PostgreSQL при правильной настройке спокойно строит B-tree индексы для объёмов данных в 500-700Гб, что для MySQL'я непосильная задача Ну и в PostgreSQL часто приходится дописывать сишные функции агрегации и строить по ним разнообразные индексы, иногда пространственные (gin/gist).

Вот небольшой обзор разных типов индексов.

От себя ещё добавлю MVP-tree для поиска похожих персептивных хэшей и Fusion-tree как более съедобный вариант дерева Ван Емде Боаса.

По поводу хипстер-культа вокруг MongoDB - скажу что PostgreSQL с индексами на хэш-таблицах и небольшими множествами документов в 1.5-3 раза шустрее, потому что "Building Index with Vodka". А нормальная репликация и партицирование напрямую зависит от принципов решения задачи Консенсуса в каждом конкретном приложении, и без понимания работы Raft / Paxos не стоит надеятся на чудеса той же MongoDB или PostgreSQL, они являются не более чем инструментами для решения этой задачи.

MongoDB очень даже ничего для реактивных проектов на основе Meteor, а для всего остального уже GoldenHammer™.

По индексации, надо обязательно-обязательно прочитать книги Ханны Самет
Foundations of Multidimensional and Metric Data St... = Applications of Spatial Data Structures: Computer ... + The Design and Analysis of Spatial Data Structures

В принципе книжки Foundations of Multidimensional and Metric Structures должно хватить с головой, но можно "дочитывать" более полное описание в более древних работах. Одним словом тётка "жжёт", и я не знаю почему это до сих пор никто не перевёл.

Ну после того как разобрались что и где и как хранить, теперь можно думать по поводу обработки...
Есть древняя книжка "Алгоритмы интеллектуального Интернета" и "Программируем коллективный разум" Хоть названия переведены на русский довольно странно и звучат довольно наивно - это хорошее введение в простые средства обработки и анализа данных.

По машинному обучению можно пройти курс Эндрю Ына на курсере.

Есть Южный DataScience-централ, там есть много чего полезного. Его можно почитывать. Есть ещё поверхностные CheetSheet'ы, видел и получше, но не нашёл.

Как DeepLearning адепт советую разобраться с Theano, и методами описанными тут. В продакшенах эта штука до безобразия слоупочна и видел товарищей которые более-менее успешно слезли на Neon.

Если лезть в Java, то на примере Spotify чаще всего используются связки
Apache Kafka -> Apache HBase -> Apache Storm -> Apache Spark (mllib) -> Apache HBase -> Apache Phoenix -> Hibernate + любой MVC фреймворк и т.п.

Естественно об относительно высокой производительности и хорошем вертикальном масштабировании речи не идёт, если брать C++11 ScyllaDB -> Neon хорошо отпрофилировать и допилить, можно получить в 3-5 раз выше производительность и соответственно гораздо меньшие задержки, но обычно всем влом. REST API под такое обычно пытаются писать на сях (без плюсов) в виде расширений под Nginx, что является довольно породистым извратом - в большинстве случаев банального golang/netty будет достаточно.

В Hadoop стэк сейчас принято не лезть, так как он очень "заынтерпрайсян" и без хорошей поддержки и допилки со стороны вендоров в реальных проектах просто неюзабелен, по этому почти все на него, в той или иной степени, забили. Например, тот же Spotify.

По поводу HA и Zookeeper можно увидеть много срача, особенно в Netflix'e, по этому для менеджмента высокой доступности лучше использовать именно их решения - eureka или для отказоустойчивости Hystrix. Хотя я не могу сказать что это достаточно зрелые проекты - в них тоже хватает изъянов, но они на много шустрее остальных Apache поделок.

Нельзя делать одновременно отказоустойчивые и высокодоступные приложения - потому что CAP теорема имеет место быть.

Ещё есть очень тонкий момент с Java в целом - нужно минимизировать время сборки мусора и лезть в offheap, стоит глянуть как реализованы буферы в netty - это arena аллокатор по типу того что используется jemalloc и различная misc.unsafe ересь. Можно ещё пробовать Hazelcast / Terracotta, но принципиально там тоже самое, только платно и "расспределённо".

Для REST API я чаще всего использую Vert.x и ванильную Java.
Overhead от Scala довольно таки большой, а время компиляции просто вырвиглазное.
Для минимизации копи-пасты вполне безопасно использовать Groovy c @ Immutable и @ CompileStatic.
Но в Vert.x'e он весь "динамичный" :|

Я ничего не могу сказать по поводу производительности Clojure, он местами через чур invokeDynamic. Естественно что ванильная Java будет шустрее, но я без понятия на сколько.

Желаю Вам приятного вечера.

p.s. не везде проставил ссылки просто потому что хочу спать.

https://github.com/zualex/devmap
images.vfl.ru/ii/1466366676/e324255d/13079149.png
www.webdesigndegreecenter.org/learn-to-code

https://www.linode.com/docs/

В идеальном мире этим должно заниматься как минимум 2-3 человека, каждый по своей специализации: админ серверный, админ/спец по базам которые вы используете и т.д.

В реальном мире это как правило делает 1 или 1.5 человека.
И нет, таких гайдов нет.
Потому что это все настраивается отдельно, не говоря про то что настроить конкретную базу на нормальную работу или сам сервер вещи вообще разные и требуют разных знаний.
Все гуглится и настраивается отдельно по мере необходимости.
А так же еще выбрать как правило всегда надо между несколькими решениями для одной задачи, т.к. вариантов настройки/софта вагон и маленькая тележка.

Логика передачи параметров следующая:
Что в html шаблоне разделяется дефисами (on-find, on-click) - то в свойстве scope пишется через camelCase (onFind, onChange);

Так что можете упростить до:

{
    users: '=',
    onFind: '&'
}

Чето мне думается что если пишете on-find то и в директиве должно быть onFind, да и если не ошибаюсь, функция должно передаваться в атрибут а не вызываться

Такс. Смотрите.

Структура конфига у nginx довольна проста.
Основной уровень - файл. Он хранит определённый набор настроек, может быть включён (приинклужен) один из другого. Есть первый файл с которого начинается чтение всей конфигурации.
Второй уровень - контекст или секция конфиг файла. Это некая область на которую будут влиять те настройки что находятся внутри. Контекст обозначается "{}". Основные контексты которые вам важны это server и location
Третий уровень абстракций - это сами параметры.

В вашем случае вам нужно в контекст вашего сервера вставить два локейшина и в каждом из них сделать прокси пасс

server {
    location / {
        proxy_pass http://server1/;
    }

    location /location2/ {
       proxy_pass http://server2/;
    }
}

Найдите в ваших конфигах то место где описана корневая директория сайта, закомментируйте это место и вместо этого вставьте мой конфиг, с правкой соотв. параметров.

А вообще есть замечательная документация на русском с примерами.

Внутри Docker только Linux, и, экспериментально, FreeBSD. Запускается нативно под Linux и, экспериментально, под FreeBSD. Под MacOSX, Windows - через виртуальную машину.

Докер - это двойная изоляция. Изоляция того, что лежит внутри контейнера Докера от операционной системы и изоляция операционной системы от того, что лежит внутри Докер. Изоляция подразумевает изоляцию всех файлов, портов, приоритетов.

Это почти виртуальная машина. Почти, да не совсем.

Есть такое понятие "ад зависимостей". Любое ПО устанавливаемое на компьютер, тянет за собой зависимости (конфигурационные файлы, статические файлы называемые обычно asset, вспомогательные утилиты/сервисы, библиотеки и пр.). Ряд из этих библиотек/утилит/сервисов несовместим друг с другом. А с учетом того, что каждая из этих библиотек/утилит/сервисов имеет и свои зависимости - ситуация еще хуже.

Например, мы используем Yandex.Cocaine, которая нормально компилируется только на Ubuntu 14.04 (и, вроде, на Debian 7). Но не под CentOS 6, 7, Debian 8, FreeBSD 9, 10, Ubuntu 15, 16 и пр. - скомпилировать его невозможно. Запускаем в этих операционных системах в Докере.

С другой стороны, и одновременно с этим, вам необходимо установить другое, более современное ПО. И одновременно более старое. Причем речь даже не идет об серьезно отличающихся версиях Linux. Например, одно ПО требует не менее Ubuntu 14.10, а другое не более Linux 14.04.

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

Таким образом, мы имеем бинарный файл запускаемый как бы в своей операционной системе.

Вы можете сказать - ба, да это же давно известная виртуальная машина. Но нет, это не так. Это так называемые контейнера. Никакой виртуальной машиной там и не пахнет. За исключением Windows и MacOSX, где работа без виртуальном машины пока экспериментально возможно только, а нормой в этих ОС является использование Докера внутри полноценной виртуальной машины.

Но виртуальные машины с Докером используются только для разработки. Для запуска в production виртуальные машины с Докер не используются.

Докер использует контейнеры операционной системы. LXC в Linux, Jails в FreeBSD. Контейнер - это область операционной системы, изолированная от основной части операционной системы. В контейнере свое дерево каталогов (включая системные /dev, /bin, /sbin и пр.), свои сетевые порты и пр. и пр.

Но при этом не используется полная виртуализация. Что существенно экономит ресурсы. Запустить 100 полноценных виртуальных машин вряд ли получится даже на мощном сервере. А вот запустить 100 контейнеров Docker даже на слабом домашнем компьютере - возможно.

Правда использование не полной виртуализации ограничивает использование операционных систем внутри контейнеров. Как правило, это специально подготовленные версии Linux или FreeBSD. Именно специально подготовленные. Windows - в принципе в контейнере запустить невозможно.

Контейнеры существовали и до Docker. Докер, строго говоря, это всего лишь очень удобный набор инструментов, собранных воедино, для управления контейнерной виртуализацией. Но очень удобный.

Зачем это используется?

Ребята из всяческих Dropbox, Facebook и и пр. гигантах, запускающие по 1 млн. различных программ в своих сервисах, столкнулись, что невозможно везде гарантировать идентичные настройки операционной системы. А это критично.

Вплоть до того, что идеально написанная и оттестированная программа на реальном сервере начинает себя вести непредсказуемо.

Поэтому кто-то из этих умных ребят родил новую концепцию - каждая программа на серверах запускается в своем индивидуальном окружении, с индивидуальными настройками операционной системы.

Более того - изначально разработчик программного обеспечения тестирует программу в контейнере Докер, с определенными настроками. И в этом же (или с такими же настройками) контейнере Докера программа уезжает на сервер.

Это позволяет гарантировать гораздо большую идентичность среды разработки и среды исполнения.

До этого люди мучались, придумывали хитрые инсталяторы...

Потом плюнули на попытки упорядочить окружение в ОС - и сейчас концепция такова - устанавливать программы на сервера вместе со своими индивидуально настроенными под них операционными системами - то есть внутри контейнеров. 1 контейнер = 1 настройка ОС = 1 программа внутри.

Другими словами:

• Докер-контейнер нужно использовать для отладки.
  
• Тот же Докер-контейнер нужно использовать и на сервере.
  

Это позволяет не трудиться с настройками "под сервер" локально на машине разработчика. Это позволяет разрабатывать на машине разработчика совершенно разные программы одновременно, которые требует несовместимых настроек операционной системы. Это позволяет давать гораздо больше гарантий, что программа на сервере будет вести себя также как и на машине разработчика. Это позволяет разрабатывать под Windows/MacOSX с удобным "прозрачным" тестированием под Linux.

Докер применим к созданию/настройке только серверного программного обеспечения под Linux (экспериментально под FreeBSD). Не для смартфонов. А если десктопов - то только программное обеспечение без GUI.

Посколько Докер позволил одним махом упростить работу разработчикам и админам и повысить качество результата - сейчас бум на Докер. Придумано огромная гора инструментов для управления развертыванием приложений созданных с Докером. Если раньше чтобы запустить 10 000 программ на 1000 серверах нужно было как минимум 3 высококвалифицированнейших девопса, которые писали кучу описаний как это сделать на Puppet, Salt, Chef, Ansible, да и то не было гарантий, это все тестилось месяцами. То сейчас с Докер даже один квалифицированных девопс может рулить миллионами программ на десятках тысяч серверов. С куда как большей гарантией, что все это заведется нормально.

UPD:

Может сложиться ложное впечатление, что разработчик готовит контейнеры в Докер, а потом передает их админу.
Правильная методология все же другая:

Разработчик отдает весь свой результат в систему CI (обычно через git)
CI на каждый новый коммит делает с помощью Docker образ для тестирования.
Если тесты проходят успешно, то этот же самый Docker образ, отправляется на развертывание в production.
Или, чуть иначе в компилируемых системах, где исходники не нужны в production: в Docker производится развертывание среды для компиляции, а для тестирования разворачивается второй образ с уже откомпилированным добром, который уже отправляется в production.

То есть при правильной огранизации дела разработчик не может/не должен влиять на то, какой будет образ.
А вот в тестовой среде (запускаемом на сервер, недоступном разработчику в больших командах) и в production как раз используется один и тот же образ.

Основная идея - что тестировали, ровно то и запускаем на боевом сервере. Один-в-один, включая те же самые файлы (не такие же, а именно те же самые).

Представьте что нет никакой ложки докера.

1) Есть одна физическая машина. Вы устанвливаете софт, разные приложухи, базы, web сервера, заходят тестовые юзеры, что-то запускают. Первая проблема - вы не понимаете кому что надо, кто владелец файлов, приложух, зачем висят демоны и кто за это ответственнен. Как выход, вы решаете это разделить на виртуалки.

2) У вас есть физическая машина + на ней виртуалки. Вы выделяете под каждую задачу свою виртуалку, там сидят отдельные пользователи, вы навели какой то порядок. Появляется задача - пользователи хотят php 6, а его нет, хотят python3, а его нет, хотят Mongo, а она старой версии. Вы обновляете репозитарии, качаете новые пакеты, ставите, часть пользователей довольны, часть нет - им нужна старая версия какая была. Упс!

3) Одна физическая машина + еще больше виртуальных машин. Вы разделили всех пользователей так, чтобы никто не дрался за версии софта, если нужен php6 - иди на эту машину, нужен php5 - вот на эту. Все счастливы, но появляются разработчики, которые говорят буквально так - "а у меня на рабочей машине все работает, я перенес все как было на виртуалку, а у меня появляется ошибка missing library libXXX.so.X". И вы понимаете что вам остается только создать полную копию машины разработчика, чтобы софт поехал на этой виртуалке без ошибок... И тут появляется Docker! :)

4) Docker решает именно эту проблему. Вам не нужно заботится о софте который установлен на сервере/виртуалке. Вы просто берете и переносите софт со всеми "кишками" на другой сервер и он просто работает. Работает за счет того, что все "кишки" это слои файловой системы нанизанные как бисер друг на друга. Дополнительно решается проблема свободного места, т.к слои многократно переиспользуются контейнерами, если вам нужен php + одна библиотека, а другому php + другая библиотека, вы используете (грубо говоря) слой php, а для дополнительной библиотеки делаете отдельный слой, одновременно другой человек делает над php другой слой и вы не деретесь между собой и не видите чужих библиотек. Это грубо и скорее всего ради одной библиотеки никто новый слой не делает, делают слой пожирнее.

Все запущенные процессы Docker помещает в изолированную среду процессов, файловой системы и сетевого стека. Есть много особенностей по работе с Docker, т.к он предполагает, что в одном контейнере вы запускаете один процесс. Если вам нужно запустить целый набор демоном, тут появляются проблемы, нужно писать шелл-скрипт, который все это поднимет в контейнере. Так же есть особенности по сети, файловой системе. Для кого то Docker спасение и решение всех проблем, но я как сисадмин от этого всего не в восторге.

если у площадки есть хоть какие то бесплтаные альтернативы (сейчас ведь они как то находят друг друга?), то платить никто не будет пока на сайте не появится трафик.

посомтрите на эти же фриланс сайты - их миллионы наверное, но платят только на тех которые имеют хороший трафик.

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

на таких площадках люди платят чтобы размещать себя выше на видном месте, если место никто не видит(нет трафика) - то платить за него глупо.

Скопируйте варианты монетизации с freelansim.ru, fl.ru, upwork.com. Эти сервися и есть с двумя типами пользователей (заказчик\исполнитель).

1. IDE
2. xdebug
3. git
4. composer
5.bower
6.npm/bower
6. less/stulys/sass
7. grunt/gulp/webpack
8. apache/nginx
9. apc/opcache/memcache/varnish etc
10. bootstrap
11. VIM!!!!!!!!!
12. English!!!!!!!!!!
13. Все дырки через границу
14. Умение не читать ИТ литературу русских программистов за исключением Макарова, Индутного
15. Ненавидеть Попова

> Есть какие либо идеи?

конечно есть идеи!
например, ты используешь адб не так, как то планировали его разработчики и он тебе ненавязчиво в очередной раз справочку кажет.
Например, если "directs command to the only connected USB device" так зачем после -d какое-то "Zera F" - это что вообще и зачем оно там?!

и вообще, если у тебя одно устройсво подключено, можно безо всяких -d. просто adb install /path/to/file.apk

Потому что ангуляр внедряет зависимости по именам аргументов. А некоторые минификаторы и компиляторы изменяют имена аргументов. В итоге всё ломается. Первый вариант используется, чтобы явно задать список имён зависимостей для внедрения.

А вообще, по-нормальному используют либо такой вариант:

angular.module('app').controller('FooController', FooController);

FooController.$inject = ['$service1', '$service2'];
function FooController($service1, $service2) {}

Либо берут это, настраивают свой сборщик (плагинов там куча) и вставляют определённый коммент где нужно:

angular.module('app').controller('FooController', FooController);

/*@ngInject*/
function FooController($service1, $service2) {}