URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 85232
[ Назад ]

Исходное сообщение
"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."

Отправлено opennews , 25-Июн-12 08:53 
Эрик Френкель (Eric Frenkiel) и Никита Шамгунов (Nikita Shamgunov), бывшие сотрудники Faebook, основали стартап, разработавший новую СУБД MemSQL (http://memsql.com/), совместимую с MySQL и удовлетворяющую требованиям ACID к выполнению транзакций (атомарность, согласованность, изолированность, долговечность), но обладающую производительностью, свойственной  хранимым в памяти NoSQL БД.  MemSQL является проприетарной разработкой, но распространяется (http://memsql.com/#download) бесплатно для разработчиков и предварительной оценки в сборах для различных Linux-дистрибутивов.


Представленные результаты тестирования производительности показывают, что в конфигурации, при которой MySQL позволяет обеспечить отдачу 3500 запросов в секунду, MemSQL способен выполнить до 80 тысяч запросов в секунду. Для тестирования использовался собственный инструментарий (https://github.com/memsql/workload-simulator) для симуляции нагруки на СУБД.


Высокая производительность в MemSQL достигается благодаря реализации нескольких интересных особенностей. Например, MemSQL не осуществляет разбор SQL на лету, вместо этого из SQL-конструкций генерируется С++ код, работающий с оптимизированными для хранения в памяти структурами данных, доступ к которым осуществляется без блокировок. Второй особенностью является то, что данные всегда полностью держатся в ОЗУ и отдаются из памяти. Для обеспечения целостности и выполнения требований ACID, хранимые в памяти данные синхронизируются на диск или SSD-накопитель с использованием техники обратной записи с последующим подтверждением выполнения операции (используется комбинация упреждающей записи в форме лога и фиксация снапшотов).

URL: http://www.i-programmer.info/news/84-database/4397-memsql-80...
Новость: http://www.opennet.me/opennews/art.shtml?num=34177


Содержание

Сообщения в этом обсуждении
"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Аноним , 25-Июн-12 08:53 
>Высокая производительность в MemSQL достигается благодаря реализации нескольких интересных особенностей. Например, в MemSQL не осуществляет разбор SQL на лету, вместо этого из SQL-конструкций генерируется и зтем компилируется С++ код

-Потенциально 10 000 уязвимостей.
>MemSQL является проприетарной разработкой,

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


"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено pavlinux , 25-Июн-12 14:45 
Последний абзац конечно прочёл?

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено ааноним , 25-Июн-12 08:55 
Думал действительно что-то интересное придумали, а "генерируется С++ код", "данные всегда полностью держатся в ОЗУ" как-то первое, что приходит в голову при желании добиться такой производительности.

"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено arisu , 25-Июн-12 13:30 
> Думал действительно что-то интересное придумали, а "генерируется С++ код", "данные всегда
> полностью держатся в ОЗУ" как-то первое, что приходит в голову при
> желании добиться такой производительности.

"генерируется C++ код" -- это сразу крест на производительности. ты прикинь, сколько времени будет выжирать вызов g++.

p.s. я понимаю, что имелась в виду скорее всего обычная JIT-компиляция (а то и просто шитый код, возможно даже не подпрограммный). но не поиздеваться над текстом новости я не мог.


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено FFASM , 25-Июн-12 14:30 
Кроме g++ альтернатив нет.

"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено arisu , 25-Июн-12 14:33 
> Кроме g++ альтернатив нет.

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


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено kurokaze , 25-Июн-12 15:11 
>а поэтому надо распарзивать кучу заголовков

Открой для себя PCH.


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено arisu , 25-Июн-12 15:29 
>>а поэтому надо распарзивать кучу заголовков
> Открой для себя PCH.

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


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено Аноним , 25-Июн-12 21:05 
> угу, их парзить не надо, они автомагически распарзиваются, за нулевое время.

Ну я могу себе вообразить продвинутый кешинг когда c++ версия буферизуется и потом немедленно доступна при таком же запросе.

Вот только если надо такие уровни производительности - это пора уже нa key-value базы смотреть, там оверхеда по определению минимум.


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено FFASM , 25-Июн-12 15:14 
>> Кроме g++ альтернатив нет.
> да без разницы: другие не сильно быстрее, если рассматривать именно «C++ код».
> ведь не сказали же, что «машинный код», а именно «C++». а
> его надо компилировать. а поэтому надо распарзивать кучу заголовков и заниматься
> прочей ненужной работой.

Больше чем наверняка предпроцессором проходить вообще не придётся.
Что касается C++ действительно не понятно, лучше всего (по скорости) C.
Хотя может они умеют очень быстро собирать C++ или на C получается слишком муторный код, так как СУБД проще всего описать через ООП.

Генерировать сразу машинный код себе дороже, будет либо не эффективно, либо почти полноценный gcc(или альтернатива) (такой же тормознутый и большой).


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено добрый дядя , 25-Июн-12 15:31 
> Генерировать сразу машинный код себе дороже, будет либо не эффективно, либо почти полноценный gcc(или альтернатива) (такой же тормознутый и большой).

man LLVM


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено arisu , 25-Июн-12 15:36 
>> Генерировать сразу машинный код себе дороже, будет либо не эффективно, либо почти полноценный gcc(или альтернатива) (такой же тормознутый и большой).
> man LLVM

ну вот и «помань». а то вы, Указующие, про llvm знаете только то, что «а вот оно может!»


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено arisu , 25-Июн-12 15:34 
> Генерировать сразу машинный код себе дороже, будет либо не эффективно, либо почти
> полноценный gcc(или альтернатива) (такой же тормознутый и большой).

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

компилятор при этом не такой и сложный получается. и шустрый. к тому же можно хранить исходную/промежуточные формы и запускать более «тяжёлые» оптимизации для запросов, которые вызывают достаточно часто. собственно, именно так и работает большинство JIT'ов.

думаю, и здесь что-то подобное сделано, а слова «C++ код» или перекочевали прямиком из рекламного проспекта, или вообще придуманы автором новости.

p.s. по крайней мере, я бы делал именно так: это проще и менее накладно, чем делать подмножество c++, реализовывать aot-компиляцию с оптимизацией и прочую ерунду, которая производит впечатление на неискушённых и вызывает улыбку у тех, кто в теме.


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено FFASM , 25-Июн-12 15:53 
>[оверквотинг удален]
> компилятор при этом не такой и сложный получается. и шустрый. к тому
> же можно хранить исходную/промежуточные формы и запускать более «тяжёлые» оптимизации
> для запросов, которые вызывают достаточно часто. собственно, именно так и работает
> большинство JIT'ов.
> думаю, и здесь что-то подобное сделано, а слова «C++ код» или перекочевали
> прямиком из рекламного проспекта, или вообще придуманы автором новости.
> p.s. по крайней мере, я бы делал именно так: это проще и
> менее накладно, чем делать подмножество c++, реализовывать aot-компиляцию с оптимизацией
> и прочую ерунду, которая производит впечатление на неискушённых и вызывает улыбку
> у тех, кто в теме.

Ничего плохого и тормозного в aot нет, а вот сделать полноценную поддержку хотябы ia64 многово стоит (учтя последние наработки, например, avx), не говоря о том, что придётся переносить на всякие там arm, mips, учитывать разные виды конвейеров и кешей, поддерживать DSP на тех, же ARM-ах и тп. Ещё замечу, что вам никто не мешает явно указать какие функции какое ABI должно использовать, где распологаться в памяти и тп.

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


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено arisu , 25-Июн-12 16:01 
> Ничего плохого и тормозного в aot нет

для изменяющихся условий, ага. позволь задать вопрос (не в плане унизить, просто для определения уровня беседы): ты в данном случае теоретик, или есть практика реализаций подобных штук? у меня — практика лет 10, от любительского «потому что интересно» до вполне рабочих джитеров в проектах «за бабло».

> а вот сделать полноценную поддержку хотябы ia64 многово стоит

не особо. к тому же — итаниум? just4lulz: дорого и неоправдано.

> (учтя последние наработки, например, avx)

ты, кажется, путаешь «достаточно хороший код» и «сильно оптимизированый код».

> о том, что придётся переносить на всякие там arm, mips

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

> учитывать разные виды конвейеров и кешей, поддерживать DSP на тех, же ARM-ах
> и тп.

зачем? задачи «сделать супероптимальный код» не стоит, для этого есть «оффлайновые» aot-компиляторы.

> Ещё замечу, что вам никто не мешает явно указать
> какие функции какое ABI должно использовать, где распологаться в памяти и
> тп.

а это тут при чём? я не понял, к чему сие было написано. поясни, плз.

> На оборот разговоры на тему "лучше наделать велосипедов — будет быстро и
> просто" вызыает улыбку у тех, кто в теме.

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

p.s. мне показалось, или ты ушёл в задачу «универсальный JIT»? я ни разу не вёл речь про универсальный JIT, только про специализированный, для конкретной области применений.


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено FFASM , 25-Июн-12 16:35 
>> Ничего плохого и тормозного в aot нет
> для изменяющихся условий, ага. позволь задать вопрос (не в плане унизить, просто
> для определения уровня беседы): ты в данном случае теоретик, или есть
> практика реализаций подобных штук? у меня — практика лет 10, от
> любительского «потому что интересно» до вполне рабочих джитеров в проектах «за
> бабло».

Меня всегда умиляли люди с практикой под 10 лет, которые качали авторитет подобным
образом. Например, я, да и вы, наверное, просидели в школе 10 лет(если не ошибусь).
Но, я вот, так и не научился на русском грамотно писать, также можно и 10-ти
летний опыт в программировании получать.

>> а вот сделать полноценную поддержку хотябы ia64 многово стоит
> не особо. к тому же — итаниум? just4lulz: дорого и неоправдано.

Виноват, я имел введу AMD64 (вечно забываю про итаниум :-))

>> (учтя последние наработки, например, avx)
> ты, кажется, путаешь «достаточно хороший код» и «сильно оптимизированый
> код».

Действительно, я не понимаю что вы предпологаете говоря "достаточно хороший код",
в нашем случае мы ждём от кода только две вещи: 1. быстро и 2. оптимизированно транслироваться в машинный код.

>> о том, что придётся переносить на всякие там arm, mips
> мипс? такую базу? зачем?
> арм? с трудом, но представляю. опять же несложно.

Думаю на desktop MemSQL может найти применение, так же как и в embedded устройствах.

>> Ещё замечу, что вам никто не мешает явно указать
>> какие функции какое ABI должно использовать, где распологаться в памяти и
>> тп.
> а это тут при чём? я не понял, к чему сие было
> написано. поясни, плз.

Ну не вы ли тут говорили о том, что надо "укладывать часто вызываемые функции рядышком",
я намекнул, что это лишь вершина айзберга.

>> На оборот разговоры на тему "лучше наделать велосипедов — будет быстро и
>> просто" вызыает улыбку у тех, кто в теме.
> угу, болельщики завсегда лучше спортсменов знают, как надо. только вот выступать что-то
> не рвутся.
> p.s. мне показалось, или ты ушёл в задачу «универсальный JIT»? я ни
> разу не вёл речь про универсальный JIT, только про специализированный, для
> конкретной области применений.

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


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено arisu , 25-Июн-12 17:04 
а меня всегда умиляли люди, которые на вопрос о наличии практики начинают «лепить отмазки». я же специально упомянул, что не для трололо спрашиваю. или выяснять профуровень собеседника и стараться подстраиваться под его опыт и знания (чтобы беседа не превратилась в соревнование вентиляторщиков) уже немодно?

> Виноват, я имел введу AMD64 (вечно забываю про итаниум :-))

а ещё это можно назвать «EM64T» и «Intel 64». %-) эту систему команд можно принять за RISC в первом приближении. x86 намного хуже и геморройней.

> Действительно, я не понимаю что вы предпологаете говоря «достаточно хороший код»,
> в нашем случае мы ждём от кода только две вещи: 1. быстро
> и 2. оптимизированно транслироваться в машинный код.

понятие «оптимизировано» очень расплывчато. «достаточно хороший код» в данном случае — это код, который работает быстрее, чем, например, bytecode vm, при этом кодогенератор не становится неуправляемым тормозным монстром и генерирует код без заметных тормозов. чем больше вбухивается в код оптимизаций, тем медленее — натурально — кодоген. увлечение генераторами «оптимального кода» — интересное занятие, но оно любит сжирать время и ресурсы на непродуктивные вещи типа «добавим ещё 100500 строчек и ускорим выходной код на два такта». в большинстве случаев это совсем ненужно.

опять же, не стоит, например, оптимизировать то, что исполняется довольно редко. и ещё много всякого.

> Думаю на desktop MemSQL может найти применение, так же как и в
> embedded устройствах.

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

> Ну не вы ли тут говорили о том, что надо "укладывать часто
> вызываемые функции рядышком",
> я намекнул, что это лишь вершина айзберга.

это всего лишь простая и очевидная оптимизация для шитого кода (которая, тем не менее, часто даёт заметный выигрыш; и при этом реализуется без особого труда). естественно, есть много других вариантов.

> Вам это показалось. Я говорю о том, что то эпическое количество оптимизаций
> который есть в любом компиляторе вы на колленке никогда не напишете

вот. я и говорю: ушёл в задачу об «универсальном JIT». собственно, это и есть отсутствие опыта и понимания, что такое JIT, зачем оно нужно и почему иногда «worse is better».

> Проще разобраться
> в том, как заставить компилятор решать вашу специализированную задачу, чем писать
> новый недокомпилятор для неё.

авторы [E]DSL-ей рвут на себе волосы: оказывается, они всё это время всё переусложняли.


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено FFASM , 25-Июн-12 17:52 
Проф уровень 0, если вас так интеерсует.

> x86 намного хуже  и геморройней.

64 не далеко ушла от x86. Как была геморойной, так и осталась.
Да и не имеет это отношение к теме.

>[оверквотинг удален]
>> в нашем случае мы ждём от кода только две вещи: 1. быстро
>> и 2. оптимизированно транслироваться в машинный код.
> понятие «оптимизировано» очень расплывчато. «достаточно хороший код»
> в данном случае — это код, который работает быстрее, чем, например,
> bytecode vm, при этом кодогенератор не становится неуправляемым тормозным монстром и
> генерирует код без заметных тормозов. чем больше вбухивается в код оптимизаций,
> тем медленее — натурально — кодоген. увлечение генераторами «оптимального
> кода» — интересное занятие, но оно любит сжирать время и ресурсы
> на непродуктивные вещи типа «добавим ещё 100500 строчек и ускорим выходной
> код на два такта». в большинстве случаев это совсем ненужно.

Спасибо КЭП. Все оптимизации, те что вам не свосем нужны, можете просто взять и выключить.

> опять же, не стоит, например, оптимизировать то, что исполняется довольно редко. и
> ещё много всякого.

В таком случае компиляете код без оптимизации, если выясняется что он выполняется часто, компиляете с нужной вам оптимизацией.

>> Думаю на desktop MemSQL может найти применение, так же как и в
>> embedded устройствах.
> база, которая требует 100500 памяти? ну, можно, конечно: вон, кдешники умудряются для
> хранения адресбука MySQL использовать. только вот есть варианты получше, чем брать
> относительно универсальный инструмент (не предназначеный, кстати, для решения подобных
> микрозадач) и пытаться его впихнуть туда, где он не нужен.

Возможно оно и не нужно, я это лишь предположил.

>> Ну не вы ли тут говорили о том, что надо "укладывать часто
>> вызываемые функции рядышком",
>> я намекнул, что это лишь вершина айзберга.
> это всего лишь простая и очевидная оптимизация для шитого кода (которая, тем
> не менее, часто даёт заметный выигрыш; и при этом реализуется без
> особого труда). естественно, есть много других вариантов.

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

>> Вам это показалось. Я говорю о том, что то эпическое количество оптимизаций
>> который есть в любом компиляторе вы на колленке никогда не напишете
> вот. я и говорю: ушёл в задачу об «универсальном JIT».

Вам опять это показалось.

>> Проще разобраться
>> в том, как заставить компилятор решать вашу специализированную задачу, чем писать
>> новый недокомпилятор для неё.
> авторы [E]DSL-ей рвут на себе волосы: оказывается, они всё это время всё
> переусложняли.

У каждого свои мнения о том, как делать правильно. Так же, как кто-то пишет на C++ и смеётся над ADA программистами.


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено arisu , 25-Июн-12 18:20 
>> x86 намного хуже  и геморройней.
> 64 не далеко ушла от x86. Как была геморойной, так и осталась.

там больше регистров, и они не так жестоко прибиты гвоздями к операциям. поэтому несколько проще.

> Спасибо КЭП. Все оптимизации, те что вам не свосем нужны, можете просто
> взять и выключить.

ок, если ты не можешь мыслить абстрактно, можно попробовать так: я пишу самопальный JIT-компилятор DSL, ты — используешь clang++/llvm или g++. потом сравниваем простоту поддержки/понимания исходного кода и общую скорость работы софтины на куче меняющихся скриптов. скорость разработки тоже учитываем. условия можно (и нужно) обговорить потом подробней, конечно — как кода/тестов, так и критерии выигрыша (хотя тут проще: кто быстрее, тот и папа). проиграю я — плачу тебе, например, десять тыщ USD. проиграешь ты — ты мне. натурально, без денег за игру не садимся, так что по электронному переводу с подтверждением, чтобы деньги висели, но снять нельзя было. можем привлечь независимых арбитров. может, я хоть так тебе что-то поясню (а глядишь, ещё и работника хорошего найду, чем чёрт не шутит).

натурально, такие критерии, как «документированность кода», «простота установки», «работа хотя бы под GNU/Linux и MS Windows» тоже входят.


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено FFASM , 25-Июн-12 18:47 
>>> x86 намного хуже  и геморройней.
>> 64 не далеко ушла от x86. Как была геморойной, так и осталась.
> там больше регистров, и они не так жестоко прибиты гвоздями к операциям.
> поэтому несколько проще.

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

>[оверквотинг удален]
> меняющихся скриптов. скорость разработки тоже учитываем. условия можно (и нужно) обговорить
> потом подробней, конечно — как кода/тестов, так и критерии выигрыша (хотя
> тут проще: кто быстрее, тот и папа). проиграю я — плачу
> тебе, например, десять тыщ USD. проиграешь ты — ты мне. натурально,
> без денег за игру не садимся, так что по электронному переводу
> с подтверждением, чтобы деньги висели, но снять нельзя было. можем привлечь
> независимых арбитров. может, я хоть так тебе что-то поясню (а глядишь,
> ещё и работника хорошего найду, чем чёрт не шутит).
> натурально, такие критерии, как «документированность кода», «простота
> установки», «работа хотя бы под GNU/Linux и MS Windows» тоже входят.

Время разработки учитывать бы не стал, так как не докажешь потом, может вы там этот DSL всем отделом писали. Понимание исходного кода тоже, так как это понятие очень и очень субъективное. Да и не забывайте уровень моей компитенции 0, я по факту буду делать много дольше, чем человек с опытом.
Так что единственный критерий это скорость работы.

> а глядишь, ещё и работника хорошего найду, чем чёрт не шутит

Какой работник пойдёт на вас работать, если обыграет?


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено arisu , 25-Июн-12 19:09 
> Время разработки учитывать бы не стал, так как не докажешь потом, может
> вы там этот DSL всем отделом писали.

ну так и я не знаю: может, вы там тоже?

> Понимание исходного кода тоже,
> так как это понятие очень и очень субъективное.

достаточно объективное, на самом деле.

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

ну и что? достаточно безапелляционные суждения ты же себе позволяешь высказывать. значит, и код сделаешь быстро и нормально, не просто же так ты высказываешься.

> Так что единственный критерий это скорость работы.

нет. очень-быстрое-нечто-понятное-только-автору нафиг не надо. «криэйторы, Вава, криэйторы, творцы нам на…й не нужны».

>> а глядишь, ещё и работника хорошего найду, чем чёрт не шутит
> Какой работник пойдёт на вас работать, если обыграет?

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


"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено ыгчч , 25-Июн-12 16:05 
> "генерируется C++ код" -- это сразу крест на производительности. ты прикинь, сколько времени будет выжирать вызов g++.

Даже в таком случае prepared statements спасут гиганта мысли :)


"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено o , 25-Июн-12 09:02 
Интересно какая нужна конфигурация для получения 3500рек/сек из мускула.
Только так чтобы не давно закешированый ответ а нормальное рандомное чтение из таблицы размером много больше оперативной памяти.

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено axe , 25-Июн-12 21:43 
с какой целью интересуетесь? Имхо смысла эта информация не имеет. Если вся таблицы будут умещаться в памяти, тогда да, можно сравнить.

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Аноним , 25-Июн-12 09:26 
Оракл, десятилетней давности. Впереди большой путь по фиксации багов, добавления поддержки стандартов и, как знать, возможно через 10 лет кто-то начнет применять в промышленных условиях...

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Аноним , 25-Июн-12 09:58 
На хабре неделю назад в комментах по полочкам разобрали почему эта «самая быстрая СУБД» не нужна.
Там же ( http://habrahabr.ru/post/146023/#comment_4913015 ) выяснилось что эта _проприетарная_ разработка во всю использует код MySQL (который вроде как GPL?)

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Челз , 25-Июн-12 10:23 
Кстати, что не характерно для хабра, разобрали довольно аргументировано.

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено анон , 25-Июн-12 12:59 
бгг. а где аргументированней разбирают? анонимы на опеннете что ль?

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Аноним , 25-Июн-12 10:10 
они там тебе че хочешь докажут. =) Как и на лоре - ничего не нужно кроме голой консоли.

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Куяврик , 25-Июн-12 12:31 
для мускуля? истинно так.
но специально для дошколят есть phpmyadmin

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено anonymous , 25-Июн-12 10:24 
>MemSQL является проприетарной разработкой
>opennet

Тут что-то не так.


"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Андрей , 25-Июн-12 13:57 
Да проприетарно и open - это несовместимо.

> но распространяется бесплатно c ограничением

А вот на "freenet" вполне можно.


"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Челз , 25-Июн-12 10:24 
кажется забыли добавить подпись "НА ПРАВАХ РЕКЛАМЫ"


"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Xasd , 25-Июн-12 10:24 
"""лучшее -- враг хорошего"""

то есть проще говоря -- вобщемто людям не нужна "самая лучшая" СУБД. им достаточна просто ХОРОШАЯ СУБД. и уж точно не проприетарная :)

...хотя любители пирацких Фотошопов и WinRAR -- возможно заценят и эту поделку тоже... но что-то я сомниваюсь о большем успехе :)


"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено SubGun , 25-Июн-12 11:20 
Только потому что проприетарная разработка? Что за бред. ПО выбирается согласно задачам, а не религиозным убеждениям.

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено анон , 25-Июн-12 13:01 
среди проприетарщины можно найти и что-то получше, чем эта "самая лучшая субд"

"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено arisu , 25-Июн-12 13:36 
> Только потому что проприетарная разработка? Что за бред. ПО выбирается согласно задачам,
> а не религиозным убеждениям.

и поэтому сия поделка не нужна: исходники для аудита ширнамассами недоступны, мегафич, которые бы оправдали использование никому не известного и не прошедшего широкое «боевое тестирование» irl продукта отсутствуют.

так что да: именно потому, что проприетарщина и пролетает. иначе нашлись бы энтузиасты, которые стали бы это пилить, ставить и тестировать. а так… ну, воткнуть блоб в чруте, погонять на паре игрушечных тестов и выкинуть.


"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Аноним , 25-Июн-12 21:02 
> Только потому что проприетарная разработка? Что за бред.

Достаточный повод чтобы обойти в новой разработке стороной. Закладываться на проприетарь сегодня - это обеспечивать себе много геморроя в будущем.


"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Аноним , 25-Июн-12 10:33 
вот еще немного, совсем чуть-чуть и начнут вывешивать новости об adware...
а что, тоже бесплатно!

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Аноним , 25-Июн-12 10:35 
>Например, MemSQL не осуществляет разбор SQL на лету, вместо этого из SQL-конструкций генерируется С++ код, работающий с оптимизированными для хранения в памяти структурами данных, доступ к которым осуществляется без блокировок. Второй особенностью является то, что данные всегда полностью держатся в ОЗУ и отдаются из памяти.

1. Вангую новый вид атак на сервер БД - С++-Инжекш :)
2. Как я понимаю, данные в памяти держаться до первого сбоя электроснабжения?..


"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Аноним , 25-Июн-12 11:19 
Читать разучился? Написано же, синхронизируется с диском.

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Аноним , 25-Июн-12 15:02 
Читать разучился? Сказано же, что синхронизируеться не сразу, а когда нить потом, ну чтобы быстро было.

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено анон , 25-Июн-12 15:17 
Читать разучился? Сказано же, что при коммите транзакции

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Аноним , 25-Июн-12 16:44 
>Хм. Что-то автор новости про ACID, похоже, немного загнул. memSQL обеспечивает транзакционную целостность ТОЛЬКО уровня "READ COMMITTED", и ТОЛЬКО в режиме "транзакция на SQL-запрос".

Паста с коммента ниже.


"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Аноним , 25-Июн-12 12:00 
Если SQL транслируется в код на С++, то можно ставить крест на динамической генерации SQL-запросов из скриптов. Или он как-то на лету транслирует, но тогда непонятно чем это от стандартного кэширования отличается.

"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено Аноним , 25-Июн-12 12:27 
кто-нибудь знает, что быстрее PostgreSQl или msSQL под 1с 8.2?

"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено Ваня , 25-Июн-12 12:39 
Для Windows - MS. Postgre медленнее и периодически встречаются глюки, когда Postgre'шники используют один механизм во всех платформах (кросс-платформенность), а в Windows данный механизм "obsolete" с приличным списком известных уязвимостей, оставленных для совместимости.

Для Linux - Postgre, просто MS ещё не выпустили.

А вообще всё зависит от размера базы. Для базы меньше 10 Гб быстрее всего файловый вариант.


"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено Аноним , 25-Июн-12 12:48 
Для Windows - PostgreSQL. MS медленнее и периодически встречаются глюки, когда Miscrosoft-овцы баги месяцами не исправляют и давно висит приличный список неисправленных известных уязвимостей, оставленных для совместимости. Ну и лицензия на MS SQL стоит от 30 тыс рублей, но и за такие деньги поддержка нулевая, только стрелки переводят. PostgreSQL бесплатен и в форуме поддержки в течение дня на любой вопрос ответят без попыток показать клиенту, что он идиот.

"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено Аноним , 26-Июн-12 10:54 
>А вообще всё зависит от размера базы. Для базы меньше 10 Гб быстрее всего файловый вариант.

а если база будет к примеру 4Гб, разве в файловом режиме 1с 8 будет не медленней работать по сети, чем в SQL-режиме? у меня база 1,6Гб и то уже на глаз сущетвенно заметно, что в файловом режиме намного медленней работает по сетке


"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено Zensey , 25-Июн-12 14:45 
Сравнение скорости работы 1С:Предприятие на MsSQL и PostrgeSQL

Былинный тред.

http://www.sql.ru/forum/actualthread.aspx?tid=528465

Каков контраст первой и второй страницы.


"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено ананим , 25-Июн-12 15:24 
И это при том, что 1с на постгри использует табличные блокировки, а на мссиквеле - построчные.

"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено ffirefox , 25-Июн-12 21:16 
> И это при том, что 1с на постгри использует табличные блокировки, а
> на мссиквеле - построчные.

1. Вид блокировок настраивается в PostgreSQL, а не в 1С. Она использует то, что дадут.
1. Вы о какой версии PostgreSQL говорите?



"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено ананим , 26-Июн-12 00:12 
1. О сертифицированной (и патченной) в 1с
2. У 1с свой язык. Он выгребет всю таблицу в автоматических блокировках и строки в программируемых в зависимости от сервера.
3. Благодоря дизайну постгри (а теперь и оракл) всё равно уделывают мссиквел.

Ещё вопросы?


"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено ffirefox , 26-Июн-12 00:59 
Ну, эту белиберду я и так знаю. Вопрос то был про версию PostgreSQL. В современных версиях можно включить построчную блокировку. Так что, ваша информация, как бы сказать, несколько устаревшая.

"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено ананим , 26-Июн-12 11:15 
Если программа говорит залочить таблицу, то сервер лочит таблицу.
И белиберда — это то, что у вас в голове.
http://www.v8.1c.ru/overview/datalockcontrol.htm

"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено ffirefox , 25-Июн-12 21:08 
> кто-нибудь знает, что быстрее PostgreSQl или msSQL под 1с 8.2?

Быстрее то, с чем умеешь и приятно работать.
У меня получается быстрее с PostgreSQl. Но я MS SQL хуже знаю.


"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено ананим , 26-Июн-12 00:15 
Не показатель.
Умей в обоих, потом советуй.

"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено ffirefox , 26-Июн-12 01:05 
Ну, похоже, PostgreSQL Вы плохо знаете, однако советуете.
Надеюсь, MS SQL Вы лучше знаете?

А советовал, Я по простой причине: для плохо настроенной системы особой разницы нет и гнаться за мифических преимуществом - глупость. Лучше вложиться в изучение инструмента.


"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено ананим , 26-Июн-12 12:33 
Вот и вложитесь.
А то складывается ощущение, что блокировки на строку вы только что открыли для себя в постгри и с криками вау пошли комментить всё подряд.

Зыж
Оракл уже тыщу лет умеет блокировки на ячейку.
А 1с на нём всё-равно лочит всю таблицу в автомате.


"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено ILYA INDIGO , 25-Июн-12 12:31 
>>...MemSQL является проприетарной разработкой...

Дальше читать бессмысленно.


"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Аноним , 25-Июн-12 12:38 
Назревает вопрос, могут ли несколько талантливых программистов за год написать полностью совместимый аналог MySQL без заимствования кода MySQL ? Нет не могут. Значит частично использовали код MySQL, но этот код под GPL, а MemSQL - проприетарщина. Вывод - имеет место нарушение GPL. Уверен, что покопавшись в потрохах их бинарников можно много пересечений с MySQL найти, которые простым обеспечением бинарной совместимости на уровне протокола не объяснить.

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Аноним , 25-Июн-12 12:41 
> Уверен, что
> покопавшись в потрохах их бинарников можно много пересечений с MySQL найти,
> которые простым обеспечением бинарной совместимости на уровне протокола не объяснить.

Не получится покопаться в потрохах, чтобы загрузить MemSQL нужно согласиться с лицензией, а лицензия http://memsql.com/agreement.html гласит:

You may not, directly or indirectly: copy, distribute, rent, lease, timeshare, operate a service bureau with, use for the benefit of a third party, reverse engineer, disassemble, decompile, attempt to discover the source code or structure, sequence and organization of, or remove any proprietary notices from, the Software.


"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено анон , 25-Июн-12 13:05 
Выделенное жирным противоречит российскому законодательству, и любой суд признает этот пункт юридически ничтожным

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено AdVv , 25-Июн-12 13:53 
Оба-на ! Ну-ка ну-ка, какому конкретно закону РФ это противоречит ?

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Аноним , 25-Июн-12 14:29 
Гражданский кодекс РФ, часть 4, статья 1280. http://www.consultant.ru/popular/gkrf4/79_2.html#p559

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Аноним , 25-Июн-12 21:01 
> Гражданский кодекс РФ, часть 4, статья 1280. http://www.consultant.ru/popular/gkrf4/79_2.html#p559

Два пива этому анонимусу :). Ну или что ему там по вкусу больше.


"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено AdVv , 26-Июн-12 02:26 
> Гражданский кодекс РФ, часть 4, статья 1280. http://www.consultant.ru/popular/gkrf4/79_2.html#p559

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


"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено Аноним , 26-Июн-12 01:17 
> Выделенное жирным противоречит российскому законодательству

И не только нашему, европейскому тоже - директива ЕС о правовой охране программ для ЭВМ (91/250/ЕЕС). Наша статья кстати, как говорит Крашенинников (на секундочку председатель комитета госдумы по гражданскому, уголовному, арбитражному и процессуальному законодательству, доктор юридических наук, председатель ассоциации юристов России, бывший министр юстиции Российской Федерации), так вот, наша статья написана на основе этой директивы, а в ней, ололо:

> Исключительные права автора на предотвращение несанкционированного воспроизведения должны подвергаться определенным ограничениям... действия по загрузке и прогону, необходимые для использования копии программы, которая была законно приобретена, и действие по коррекции ее ошибок не могут быть запрещены договором.
> Лицо, имеющее право использовать копию программы для ЭВМ, вправе без разрешения правообладателя изучать, исследовать или испытывать функционирование программы в целях определения идей и принципов, лежащих в основе любого элемента программы, если оно при этом осуществляет любые из действий по загрузке, воспроизведению на дисплее, прогону или запоминанию программы, которые оно вправе осуществлять.

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

Пруф - Постатейный комментарий глав 70-71 ГК РФ под редакцией П.В. Крашенинникова. Издание предназначено для студентов, аспирантов и преподавателей юридических вузов, судей, адвокатов, сотрудников юридических служб организаций, авторов, и т.п.

Штука новая, 2010г, возможно некоторые юристы еще не в курсе :)


"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."
Отправлено анон , 25-Июн-12 13:06 
У мускула двойное лицензирование

"MemSQL - претендент за звание самой быстрой СУБД,..."
Отправлено arisu , 25-Июн-12 13:40 
> Назревает вопрос, могут ли несколько талантливых программистов за год написать полностью
> совместимый аналог MySQL без заимствования кода MySQL ? Нет не могут.

с чего бы это? документация на диалект sql открыта. интерфейсы клиента открыты. какие проблемы сделать совместимую реализацию? или ты где-то углядел в новости «совместимость по файловым форматам» и ты пы?


"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено б.б. , 25-Июн-12 12:44 
Кому в 2012 году может понадобиться закрытая БД без репутации в десятки лет?

"MemSQL - претендент за звание одной из самых быстрых..."
Отправлено arisu , 25-Июн-12 13:42 
> Кому в 2012 году может понадобиться закрытая БД без репутации в десятки
> лет?

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


"MemSQL - претендент за звание одной из самых быстрых..."
Отправлено arisu , 25-Июн-12 13:27 
ясно. унылая ерунда, с рекламой которой прибежали на опеннет. да ещё и проприетарная, что вообще ни в какие ворота. вот зачем сюда тащить новости про всякое гуано?

"MemSQL - претендент за звание одной из самых быстрых..."
Отправлено Аноним , 25-Июн-12 14:12 
> новости про всякое гуано?

Вот я тоже не понимаю - зачем писать новости про всякие оперы и прочие маргинальные фигни.


"MemSQL - претендент за звание одной из самых быстрых..."
Отправлено arisu , 25-Июн-12 14:17 
(пожимает плечами) увы. никто кроме апруверов не знает, я полагаю. есть, впрочем, подозрение, что не знают даже сами апруверы.

"MemSQL - претендент за звание одной из самых быстрых..."
Отправлено Аноним , 25-Июн-12 21:49 
ибо врага надо знать в лицо!

"MemSQL - претендент за звание одной из самых быстрых..."
Отправлено arisu , 25-Июн-12 21:50 
> ибо врага надо знать в лицо!

это ты так намекаешь, что надо и новости о выходе очередного KB для винды сюда постить?


"MemSQL - претендент за звание одной из самых быстрых..."
Отправлено Аноним , 26-Июн-12 01:57 
нет, не тот масштаб

"MemSQL - претендент за звание одной из самых быстрых..."
Отправлено arisu , 26-Июн-12 01:58 
> нет, не тот масштаб

в смысле — опеннет слишком мелкий для этого сайт? хм… может быть, поэтому и не постят.


"MemSQL - претендент за звание одной из самых быстрых..."
Отправлено Аноним , 26-Июн-12 02:08 
в смысле KB это слишком мелкая штука, таких последствий как топик в перспективе вызвать не может.

"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено Crazy Alex , 25-Июн-12 14:04 
Тьфу, кто писал заключительный абзац? Mongo, оперирующая парами "ключ-значение" - это песня.

"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено Kodirr , 25-Июн-12 14:53 
Месье хочет, уподобившись граммар-наци, указать на вопиющую несуразность выражения "ключ-значение", тем самым повысить своё ЧСВ? Сударь, вы лох, расслабьтесь: http://www.google.co.za/search?hl=en&q=key+value+site%3...

"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено Crazy Alex , 25-Июн-12 18:03 
Вы идиот.

Mongo - ДОКУМЕНТНАЯ (Document-oriented) база, а ни разу не "ключ-значение". О чем и написано на первой странице сайта первым пунктом.

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


"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено Аноним , 25-Июн-12 14:11 
> является проприетарной разработкой, но распространяется бесплатно c ограничением

Первая доза - бесплатно...


"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено Kodirr , 25-Июн-12 14:51 
Хранить всё в памяти - много ума не надо! Ты попробуй хранить хотя бы 100 гигов, да отдавать всё быстрее пули.
Да и в целом, не таков запрос на скорость, сколь велик запрос на надёжность и защиту.

"MemSQL - претендент за звание одной из самых быстрых СУБД, у..."
Отправлено Andrew Kolchoogin , 25-Июн-12 15:03 
Хм. Что-то автор новости про ACID, похоже, немного загнул. memSQL обеспечивает транзакционную целостность ТОЛЬКО уровня "READ COMMITTED", и ТОЛЬКО в режиме "транзакция на SQL-запрос".