Как нужно зарабывать деньги на OpenSource

Почему ты так не любишь Ъ?

что это?

по ссылке маркетинговый буллшит. Оно хотя бы может соревноваться с sqlite(':memory:') или mysql с memory engine ? :)

Будь ласка, принеси це на ЛОР для Ъ.

Пфф! pdf еще. За такие ссылки скор снимать нужно, я считаю.

Взяли Mysql и засунули его в память

$3 млн

Не, ну это вообще пушка.

Прозреваю, что внутри либо NDB, либо sqlite(':memory:'), либо SQL-обвязка вокруг Redis/KyotoCabinet, и где-то в недрах /usr/share/doc/memsql/COPYRIGHT хитрая рожа Денискина. Как по-другому за неделю представить готовый продукт, даже за 3 мегабакса, я слабо представляю.

Не, ну это вообще пушка.

Куда смотрит Навальный?!

ничего, gpl-viloations их вскоре за жопу возьмет.

В двух раундах их стартап MemSQL привлёк уже чуть больше $5 млн. от Эштона Катчера

Это что, тот Кучер, который в «Эффекте бабочки» играл, еще и SQL-базы спонсирует? Ну теперь он однозначно мой любимый актер.

я уже скачиваю, но оно весит 114 метров в архиве, на моём канале это займёт время. Но я уже вижу «MemSQL is wire-compatible with MySQL». Там grep mysql почти ничего не находит, но... Знаешь, когда в errmesage пишут «Do you already have another mysqld server?» тут всё становитсяя понятно.

Но я ещё поковыряюсь

Взяли Mysql и засунули его в память

Хабраэксперт?

MemSQL places data into memory and translates SQL into C++ for the utmost optimization in query execution.

translates SQL into C++

О_О до чего техника дошла!

честно говоря, пока явных следов mysql не нашёл.

114 метров в архиве

В архиве есть исходники?

Куда смотрит Навальный?!

А разве это деньги Навального воруют?

Предпочитаешь docx?

Предпочитаю plaintext

mysql -u root -h 127.0.0.1 -P 3307 --prompt=«memsql> »

ИМХО этого хватит, чтобы взять за жопу за нарушение GPL, если сырцов нет.

Где ты видел маркетоидные материалы без графичков?

чтобы взять за жопу за нарушение GPL

не факт. Это всего лишь протокол.

В архиве есть исходники?

есть, но, похоже, не самой тулзы а сопутствующих либ итп.

Shutdown complete

ну вот да, настораживает :). Я через objdump прогнал бинари, но сходу ничего не нашёл подозрительного. Возможно, они sed-ом выпилили все упоминания mysql, хз :).

К сожалению нет времени ковыряться.

Короче, всё бы объяснили бенчмарки. Я так и не понял степень стыренности с mysql. А так же нет цен.

В двух раундах их стартап MemSQL привлёк уже чуть больше $5 млн. от Эштона Катчера

Казалось бы - причём тут Эштон Катчер?

Эштон реально возомнил себя Джобсом. :D
Вот что роль в фильме с людьми делает...

Чем оно лучше MySQL + memory engine?

И да, про ускорение - маркетинговый бред.

translates SQL into C++

Мамочки...

Мамочки...

они просто убрали «посредника», на деле запрос так или иначе дергает плюсовые (сишные) методы, пусть запрос был преобразован в набор команд для VM, или это обход дерева от парсера, можно конечно закешировать программу для VM или то же дерево, но лишние действия будут оставаться; другой вопрос - много ли они от этого выиграют, как по мне - погоды оно не сделает

and translates SQL into C++ for the utmost optimization in query execution

C++ же известен тем, что для него принципиально невозможно создать быстрый компилятор/интерпретатор. Да и вообще C++ никак не подходит на роль промежуточного языка. Раз уж захотели повысить производительность за счет компиляции запросов вместо интерпретации (очень сомнительная техника в данном случае), то ИМХО намного адекватнее - заюзать LLVM или что-то подобное.

они просто убрали «посредника»

Напротив, добавили лишнего посредника: теперь им нужно дергать компилятор с++.

VM

«Semantics of C and C++ are described in terms of a theoretical «abstract machine»»

C++ же известен тем, что для него принципиально невозможно создать быстрый компилятор/интерпретатор.

скопилировать одну единицу, где будут только несколько прототипов функций + код без шаблонов и пр., можно практически моментально

Да и вообще C++ никак не подходит на роль промежуточного языка

представь цикл для обхода курсора, код на С++ напрямую дергает API СУБД (включая приватные методы), все работает с максимальной скоростью, код на SQL же интерпретируется и выполняются лишние побочные действия

то ИМХО намного адекватнее - заюзать LLVM или что-то подобное.

возможно они его и взяли

Напротив, добавили лишнего посредника: теперь им нужно дергать компилятор с++.

но удалили интерпретатор

«Semantics of C and C++ are described in terms of a theoretical «abstract machine»»

речь идет о рантайме

но удалили интерпретатор

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

гуру предложит лучший метод?

Это единственный годный фильм с ним.

Оракл же уже обещал ускорение MySQL на 1500%. Они его перегнали?

Основатели MemSQL и их инвесторы делают ставку на постоянный рост объёмов непрерывно обрабатываемых данных

их объём растет вдвое каждые полтора года

У них-таки есть способ преодолеть экспоненциальный рост?

Если только там не подмножество C++.

скопилировать одну единицу, где будут только несколько прототипов функций + код без шаблонов и пр., можно практически моментально

Но это все равно будет медленно. Медленнее, чем если бы вместо C++ сразу генерировался LLVM-байткод, а из него - нативный код. Тем более, что если там действительно несколько прототипов + код без шаблонов, то за счет C++ нет выигрыша даже в плане простоты.

представь цикл для обхода курсора, код на С++ напрямую дергает API СУБД (включая приватные методы), все работает с максимальной скоростью, код на SQL же интерпретируется и выполняются лишние побочные действия

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

возможно они его и взяли

Есть разница между «использовать компилятор C++, использующий LLVM» и «использовать LLVM». В первом случае добавляется еще несколько промежуточных слоев, один из которых очень времязатратный.

Ах да, ради компиляции C++ нужно дергать внешнюю программу (если, конечно, они не используют libclang) и, если они не используют libclang, дергать файловую систему. Две очень дорогостоящие операции.

JIT посредством C++ не дает тех плюшек, которые дает обычный JIT в сравнении со статической компиляцией.

Медленнее, чем если бы вместо C++ сразу генерировался LLVM-байткод, а из него - нативный код
Тот же LLVM-биткод.

генерированный код должен дергать плюсовое API СУБД, генерация «LLVM-байткода» потребует от тебя написания своего компилятора под плюсовое ABI - сизифов труд, clang сделает это за тебя без особого оверхеда, причем твой код будет гораздо более прозрачен и понятен

Ах да, ради компиляции C++ нужно дергать внешнюю программу (если, конечно, они не используют libclang) и, если они не используют libclang, дергать файловую систему. Две очень дорогостоящие операции.

давай еще предположим, что clang будет располагаться на далеком сервере и оттуда же будет присылаться результат :) конечно же надо брать libclang, ее для этого и сделали

гуру предложит лучший метод?

Использовать специальные инструменты, предназначенные для JIT. LLVM, GNU Lightning, libjit.

И еще вот какое соображение. Общее время работы складывается из времени-на-компиляцию и времени-на-исполнение. Если ты используешь слишком умный компилятор (скажем, g++ -Ofast), то может оказаться, что он потратит на компиляцию в тысячи раз больше времени, чем примитивнейший интерпретатор потратил бы на исполнение той же программы. В случае JIT есть возможность расставить профилирующие счетчики, и по мере работы программы инвестировать процессорное время в оптимизацию лишь тех участков кода, где она действительно оправдана - согласно показаниям счетчиков. Как видишь, c++ тут совсем не в тему.

генерированный код должен дергать плюсовое API СУБД, генерация «LLVM-байткода» потребует от тебя написания своего компилятора под плюсовое ABI - сизифов труд, clang сделает это за тебя без особого оверхеда, причем твой код будет гораздо более прозрачен и понятен

Если так уж нереально лень напрямую работать с плюсовым ABI, то можно сделать к плюсовому мускулю сишный апи, тогда никаких ABI-трудностей не будет.

clang сделает это за тебя без особого оверхеда

Компилировать C++, когда этого возможно избежать - это «без особого оверхеда»?

давай еще предположим, что clang будет располагаться на далеком сервере и оттуда же будет присылаться результат :) конечно же надо брать libclang, ее для этого и сделали

Мы же не видели, как они это сделали. Может, там вообще не clang используется?

Использовать специальные инструменты, предназначенные для JIT. LLVM, GNU Lightning, libjit.

вы сначала скажите - к чему вы будете JIT применять, что это за промежуточный код - откуда он возьмется и что он будет дергать?

Если ты используешь слишком умный компилятор (скажем, g++ -Ofast), то может оказаться, что он потратит на компиляцию в тысячи раз больше времени, чем примитивнейший интерпретатор потратил бы на ее исполнение.
В случае JIT есть возможность расставить профилирующие счетчики, и по мере работы программы инвестировать процессорное время в оптимизацию лишь тех участков кода, где она действительно оправдана - согласно показаниям счетчиков.

все просто - определенный запрос долго выполняется и так уже несколько раз? марш на компиляцию

можно сделать к плюсовому мускулю сишный апи

городить для плюсового ядра сишный API со своим оверхедом и лишним кодом..., можно конечно, но зачем? для упрощения своей жизни? ну так есть еще более простой вариант, вы его знаете

Компилировать C++, когда этого возможно избежать - это «без особого оверхеда»?

ес-но - времени это займет минимум, гораздо меньше чем выполняются тяжелые запросы

Мы же не видели, как они это сделали. Может, там вообще не clang используется?

может

ес-но - времени это займет минимум, гораздо меньше чем выполняются тяжелые запросы

Дело в том, что большинство запросов к базе тяжелыми или слишком сложными не являются. Их быстрее проинтерпретировать, чем тратить процессорное время на C++.

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

Это тот самый код, который авторы зачем-то генерируют для абстрактной машины c++.

Дело в том, что большинство запросов к базе тяжелыми или слишком сложными не являются

сделать миллион вставок - не тяжело, не сложно, но если СУБД отловит такой момент, то его можно значительно ускорить