А на самом деле спасибо. Такой ужасный дизайн наконец-то подтолкнул меня написать свой стиль для хабра. Теперь мне удобно. Уверен, что вы в статистике посещаемости изменений не заметите. Такая уж аудитория у хабра, что плохой дизайн просто исправляют все.
HList напоминает Union Type. Наверное мне пора серьёзнее посмотреть на Shapeless.
Не совсем понятно применение. Экономии на количестве классов в JVM не получается, потому что «object Person» создаст класс «Person$». Чтобы избежать copy-paste на однотипных операциях можно использовать дженерики, хоть там type erasure и ограничивает возможности узнавать тип в рантайме. Но в паре с Typeclass pattern (см. например мой блог) можно это обойти, да ещё и перенести обработку выбора кода для конкретного типа на этап компиляции.
Пример с delta был бы интересен. Особенно чем он отличается от
case class Person(val name: String, val address: Option[String])
val john = Person("John", None)
val john2 = john.copy(address = Some("22b Baker st")
Если принято решение самостоятельно управлять памятью, так пожалуйста — добро пожаловать в off-heap. У Hazelcast кажется была бесплатная версия хотя бы. Или на ByteBuffer.allocateDirect() можно безболезненно перейти (но он не гарантирован в off-heap). Ну и я бы не был столь категоричен с «нельзя память отдавать на откуп GC». У меня были приличные БД в продакшене на Cassandra и SOLR (и видел ещё на ElasticSearch). Как раз базы данных на Java, но к ним написано руководство по GC-tuning. JVM GC может оказаться хорошим другом, если он настроен правильно.
Вы не подумайте, что я ругаю. Несколько негативный тон комментария просто реакция на (на мой взгляд) черезмерно радужный посыл основной статьи. Так сказать предупреждение — подумайте хорошо: действительно ли вам подходит это решение.
А если есть желание помочь авторам допилить эту БД: то конечно помогайте. Код довольно читаемый, кое-где комментарии бы не помешали, но самые критичные места откомментированы. Разве что пугает объём этого кода… Ну так это же БД.
Было бы интересно привести пример. Потому что в моём случае выдача DDg намного более релевантная чем у других. Например, искал кое-какие собственные статьи из standalone блога. Утка всё находила, а Google вообще дуб дубом. Ситуация с гуглом исправилась только после посещения какой-то страницы для веб-мастеров и ручной отправки адреса блога crawler'у для индексации.
Проблема с гуглом стала в том, что слишком много сайтописателей ставят шпиона Google Analytics и Google стал слишком полагаться на данные оттуда. Поэтому целые сектора интернета для него «невидимы». У DuckDuckGo же свой crawler, который именно что и ходит по ссылком и достаточно наличия релевантных ссылок на сайт чтобы он оказался проиндексирован.
Посмотрел код… Мне кажется что производительность будет ужасная, особенно когда будет сделана попытка добавить устойчивость к сбоям, репликацию и масштабирование. Очень неприятно выглядит реализованная система типов и алгебра поверх нативных типов JVM. С одной стороны она очень примитивная (особенно по сравнению с postgresql), с другой стороны очень многословная. Я проследил выполнение функции max, которая SQL_MAX в исходниках. Код написал в «лучших» традициях энтерпрайзной Java. На пути выполнения простой функции встречаются десятки фабрик, классов-обёрток и прочего. И бОльшая часть кода отвечает за выведение типа и поиск к нему компаратора, а не собственно поиск максимального элемента. Плюс если у меня будет триллион записей типа int и одна последняя какого-нибудь несравнимого с int типа, то max вычислит max для всего триллиона и только на последней записи отправит Exception, что тип для всего выражения не вывелся.
Посмотрел и публикации. Более интересным показалось управление памятью в Hyracks ( code.google.com/p/hyracks ). Хотя я плохо понимаю зачем писать на Java, если при этом используется кастомный менеджер памяти почти для всего. Причём кастомный менеджер памяти использует ByteBuffer.allocate(), который создаёт массив внутри JVM Heap. То есть память получается под управлением родного JVM GC и кастомного внутри Hyracks.
В общем, проект молодой и исследовательский. Поэтому написан свой язык запросов, своя библиотека парсера, своя система типов и своя алгебра. Свой менеджер памяти и менеджер задач. Ничего не имею против, студентам очень полезно всё это писать и изучать. Но вот использовать результат в продакшене я бы не советовал.
Кстати такое будет работать. Можно будет делать push для /user/profile/summary и /user/profile/full (см мой коммент ниже для деталей) и ответ на оригинальный запрос /user/profile завершать когда все составные части запушились (и завершать тогда без контента).
Отвечу вместо автора. У одного моего сервиса был API вызов, в котором часть данных было гарантированно в кэше, а часть надо было запрашивать в БД. Если кратко, то там было вроде /user/profile?style=summary и /user/profile?style=full. То что для Summary спрашивается везде и гарантированно в кэше (для залогированного пользователя). Так вот, при ответе на запрос с style=full, можно было бы послать «summary» часть сразу, а расширенную дослать когда она соберётся из БД.
Конечно в этом случае можно обойтись двумя запросами и обработать на клиенте. Но было бы здорово сохранить API чистым и красивым, а все хаки для производительности спрятать. Тем более что состав быстрой и закэшированной части мог бы меняться без изменения API таким образом.
Заинтересовался и посмотрел. Действительно на уровне API принимает double и конвертирует в int64_t. Странное решение, но на уровне протокола всё нормально. Только пользователям будем неудобно, нельзя посылать количество денег, которое бы и можно бы выразить на уровне протокола, да точности параметров API не хватает.
Ещё забавная проверка на «dAmount > 21000000.0». API не даст даже попытаться послать все деньги в мире сразу :)
Но, по крайней мере, на уровне bitcoin протокола всё в порядке.
Конечно не ново, но мне кажется надо каждые лет пять-семь постить такой текст. Чтобы очередное поколение «хакеров» выучило. А то будут снова деньги через double считать…
Красивая легенда. В неё даже можно было бы поверить, если бы я не видел людей именно так держащих телефон во время разговора. И знаете почему? А потому что «Сенсорный экран, покрытый стеклом Gorilla Glass 3, по традиции отличается высокой чувствительностью и позволяет управлять смартфоном в перчатках[, а так же срабатывать от любого неосторожного движения]».
Не буду советовать что Вам самим стоит искоренять. Просто перечитайте собственный комментарий, пожалуйста.
Когдя я вижу людей вот так эргономично использующих телефон мне кажется что где-то прогресс пошёл не туда. А теперь даже в маркетинговой картинке такой ужас показать могут…
Не совсем понятно применение. Экономии на количестве классов в JVM не получается, потому что «object Person» создаст класс «Person$». Чтобы избежать copy-paste на однотипных операциях можно использовать дженерики, хоть там type erasure и ограничивает возможности узнавать тип в рантайме. Но в паре с Typeclass pattern (см. например мой блог) можно это обойти, да ещё и перенести обработку выбора кода для конкретного типа на этап компиляции.
Пример с delta был бы интересен. Особенно чем он отличается от
Вы не подумайте, что я ругаю. Несколько негативный тон комментария просто реакция на (на мой взгляд) черезмерно радужный посыл основной статьи. Так сказать предупреждение — подумайте хорошо: действительно ли вам подходит это решение.
А если есть желание помочь авторам допилить эту БД: то конечно помогайте. Код довольно читаемый, кое-где комментарии бы не помешали, но самые критичные места откомментированы. Разве что пугает объём этого кода… Ну так это же БД.
Проблема с гуглом стала в том, что слишком много сайтописателей ставят шпиона Google Analytics и Google стал слишком полагаться на данные оттуда. Поэтому целые сектора интернета для него «невидимы». У DuckDuckGo же свой crawler, который именно что и ходит по ссылком и достаточно наличия релевантных ссылок на сайт чтобы он оказался проиндексирован.
Посмотрел код… Мне кажется что производительность будет ужасная, особенно когда будет сделана попытка добавить устойчивость к сбоям, репликацию и масштабирование. Очень неприятно выглядит реализованная система типов и алгебра поверх нативных типов JVM. С одной стороны она очень примитивная (особенно по сравнению с postgresql), с другой стороны очень многословная. Я проследил выполнение функции max, которая SQL_MAX в исходниках. Код написал в «лучших» традициях энтерпрайзной Java. На пути выполнения простой функции встречаются десятки фабрик, классов-обёрток и прочего. И бОльшая часть кода отвечает за выведение типа и поиск к нему компаратора, а не собственно поиск максимального элемента. Плюс если у меня будет триллион записей типа int и одна последняя какого-нибудь несравнимого с int типа, то max вычислит max для всего триллиона и только на последней записи отправит Exception, что тип для всего выражения не вывелся.
Посмотрел и публикации. Более интересным показалось управление памятью в Hyracks ( code.google.com/p/hyracks ). Хотя я плохо понимаю зачем писать на Java, если при этом используется кастомный менеджер памяти почти для всего. Причём кастомный менеджер памяти использует ByteBuffer.allocate(), который создаёт массив внутри JVM Heap. То есть память получается под управлением родного JVM GC и кастомного внутри Hyracks.
В общем, проект молодой и исследовательский. Поэтому написан свой язык запросов, своя библиотека парсера, своя система типов и своя алгебра. Свой менеджер памяти и менеджер задач. Ничего не имею против, студентам очень полезно всё это писать и изучать. Но вот использовать результат в продакшене я бы не советовал.
Спасибо.
Конечно в этом случае можно обойтись двумя запросами и обработать на клиенте. Но было бы здорово сохранить API чистым и красивым, а все хаки для производительности спрятать. Тем более что состав быстрой и закэшированной части мог бы меняться без изменения API таким образом.
Ещё забавная проверка на «dAmount > 21000000.0». API не даст даже попытаться послать все деньги в мире сразу :)
Но, по крайней мере, на уровне bitcoin протокола всё в порядке.
Но всё равно:
И мне что-то кажется что только вот из-за этого:
versus
Не буду советовать что Вам самим стоит искоренять. Просто перечитайте собственный комментарий, пожалуйста.