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. не везде проставил ссылки просто потому что хочу спать.
Эту точку, обозначенную на схеме Gnd, полагается заземлять, но если заземления нет (например, электророзетка не 3, а 2-контактная), то из-за этого емкостного делителя напряжения на ней получается половина сетевых 220 вольт, т.е. 110. Ёмкость этих конденсаторов небольшая (несколько нанофарад), и даже в наихудшем случае ток через них будет неопасной для жизни величины (не больше долей миллиампера). Тем не менее такого тока достаточно, чтобы пощипать кожу ваших пальцев и потрепать ваши нервы.
