• Важно ли Junior Java знать алгоритмы и структуры данных?

    saboteur_kiev
    @saboteur_kiev Куратор тега Программирование
    software engineer
    Структуры данных - обязательно. Вы же с данными работать будете, как можно не знать структуры.

    Алгоритмы - основы.
    Почитать про сортировку, написать реализацию одной, любой, хотя бы пузырьковой.
    Погуглить несколько других и посмотреть их визуализацию.
    Почитать алгоритмы обхода данных (обходы массивов, графов. Написать реализацию обхода графов в глубину и в ширину). Всего делов на 2-3 дня.
    Ответ написан
    5 комментариев
  • С чего начать изучать BigData?

    voidnugget
    @voidnugget
    Программист-прагматик
    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. не везде проставил ссылки просто потому что хочу спать.
    Ответ написан
    4 комментария
  • Как организовать разделы диска для Linux?

    Дело вкуса.
    На домашних машинах делаю так:
    / - под систему (80 gb хватает, как правило, за глаза)
    /tmp - 2 gb
    /home - максимальное количество пространства
    swap - 2-4gb

    Ну и попутно.
    Если есть два диска, то ничто не мешает указать /home на второй диск, тогда как всё остальное - на первом.
    Т.е. если эксперимент не удался и очень хочется переустановить систему (зачем?), то /home останется на втором диске.

    А в целом, можно всё и на одном диске.
    Форматируем же разделы только те, которые хотим отформатировать.
    Зачем форматировать раздел /home?

    В данном случае эти разделы ( / , /tmp , swap , /home ) и есть такие вот диски c:, d:, e:...
    Ответ написан
    15 комментариев
  • Как реализовать клиент-серверное лицензирование приложения?

    Работа с СУБД предполагается?
    Какие типы данных будет передаваться по сети?
    На сколько критична потеря данных при передачи, или ее порядок доставки до клиента?
    Ответ написан
    4 комментария
  • Как выбрать данные из вложенного запроса MySQL?

    Переписать на JOIN, и всё будет понятнее, веселее и проще.
    Ответ написан
    7 комментариев
  • Трансляция видео стрима с помощью HTML5 Websockets?

    qfox
    @qfox
    Ответы есть у меня
    Не очень понятно зачем это делать через websocket, но даже если представить какой объем вы будете через них отправлять — качество будет того.

    Можно попробовать посмотреть в сторону решений типа https://github.com/phoboslab/jsmpeg, но это на nodejs и требует ffmpeg/VLC.
    Ответ написан
    4 комментария
  • Как организвовать многопоточное взаимодействие с БД в Java?

    ehabarov
    @ehabarov
    IT Specialist
    Подход из мира JEE (и не только):

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

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

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

    Примеры реализации пулов соединений:
    Apache Commons DBCP
    c3p0:JDBC DataSources/Resource Pools
    The Tomcat JDBC Connection Pool
    Ответ написан
    Комментировать
  • Кластеризованный игровой сервер на Java: реально ли?

    hrls
    @hrls
    Это просто идеальная задача для Akka.
    Сообщения - простая сериализация поверх protobuf, отказоустойчивость и балансировка с роутингом, кластеризация - все это из коробки.

    Вообщем Akka - лучше не найдете.
    Ответ написан
    Комментировать
  • Где почитать про websockets как замену ajax (как с поддержкой)?

    @DDanya
    Если ты хочешь использовать websockets для работы из PHP с PHP, то забудь про них..
    Ответ написан
    4 комментария