Эрик Френкель (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 достигается благодаря реализации нескольких интересных особенностей. Например, в MemSQL не осуществляет разбор SQL на лету, вместо этого из SQL-конструкций генерируется и зтем компилируется С++ код-Потенциально 10 000 уязвимостей.
>MemSQL является проприетарной разработкой,- о которых вы никогда и не узнаете. Точнее узнаете, когда юные какеры будут тренироваться на базе ваших паролей.
Последний абзац конечно прочёл?
Думал действительно что-то интересное придумали, а "генерируется С++ код", "данные всегда полностью держатся в ОЗУ" как-то первое, что приходит в голову при желании добиться такой производительности.
> Думал действительно что-то интересное придумали, а "генерируется С++ код", "данные всегда
> полностью держатся в ОЗУ" как-то первое, что приходит в голову при
> желании добиться такой производительности."генерируется C++ код" -- это сразу крест на производительности. ты прикинь, сколько времени будет выжирать вызов g++.
p.s. я понимаю, что имелась в виду скорее всего обычная JIT-компиляция (а то и просто шитый код, возможно даже не подпрограммный). но не поиздеваться над текстом новости я не мог.
Кроме g++ альтернатив нет.
> Кроме g++ альтернатив нет.да без разницы: другие не сильно быстрее, если рассматривать именно «C++ код». ведь не сказали же, что «машинный код», а именно «C++». а его надо компилировать. а поэтому надо распарзивать кучу заголовков и заниматься прочей ненужной работой.
>а поэтому надо распарзивать кучу заголовковОткрой для себя PCH.
>>а поэтому надо распарзивать кучу заголовков
> Открой для себя PCH.угу, их парзить не надо, они автомагически распарзиваются, за нулевое время.
> угу, их парзить не надо, они автомагически распарзиваются, за нулевое время.Ну я могу себе вообразить продвинутый кешинг когда c++ версия буферизуется и потом немедленно доступна при таком же запросе.
Вот только если надо такие уровни производительности - это пора уже нa key-value базы смотреть, там оверхеда по определению минимум.
>> Кроме g++ альтернатив нет.
> да без разницы: другие не сильно быстрее, если рассматривать именно «C++ код».
> ведь не сказали же, что «машинный код», а именно «C++». а
> его надо компилировать. а поэтому надо распарзивать кучу заголовков и заниматься
> прочей ненужной работой.Больше чем наверняка предпроцессором проходить вообще не придётся.
Что касается C++ действительно не понятно, лучше всего (по скорости) C.
Хотя может они умеют очень быстро собирать C++ или на C получается слишком муторный код, так как СУБД проще всего описать через ООП.Генерировать сразу машинный код себе дороже, будет либо не эффективно, либо почти полноценный gcc(или альтернатива) (такой же тормознутый и большой).
> Генерировать сразу машинный код себе дороже, будет либо не эффективно, либо почти полноценный gcc(или альтернатива) (такой же тормознутый и большой).man LLVM
>> Генерировать сразу машинный код себе дороже, будет либо не эффективно, либо почти полноценный gcc(или альтернатива) (такой же тормознутый и большой).
> man LLVMну вот и «помань». а то вы, Указующие, про llvm знаете только то, что «а вот оно может!»
> Генерировать сразу машинный код себе дороже, будет либо не эффективно, либо почти
> полноценный gcc(или альтернатива) (такой же тормознутый и большой).да ни разу. даже комбинация подпрограммного шитого кода с инлайнингом в стратегических местах даст ускорение, особенно если при этом укладывать часто вызываемые функции рядышком, чтобы кэш не сильно мазал.
компилятор при этом не такой и сложный получается. и шустрый. к тому же можно хранить исходную/промежуточные формы и запускать более «тяжёлые» оптимизации для запросов, которые вызывают достаточно часто. собственно, именно так и работает большинство JIT'ов.
думаю, и здесь что-то подобное сделано, а слова «C++ код» или перекочевали прямиком из рекламного проспекта, или вообще придуманы автором новости.
p.s. по крайней мере, я бы делал именно так: это проще и менее накладно, чем делать подмножество c++, реализовывать aot-компиляцию с оптимизацией и прочую ерунду, которая производит впечатление на неискушённых и вызывает улыбку у тех, кто в теме.
>[оверквотинг удален]
> компилятор при этом не такой и сложный получается. и шустрый. к тому
> же можно хранить исходную/промежуточные формы и запускать более «тяжёлые» оптимизации
> для запросов, которые вызывают достаточно часто. собственно, именно так и работает
> большинство JIT'ов.
> думаю, и здесь что-то подобное сделано, а слова «C++ код» или перекочевали
> прямиком из рекламного проспекта, или вообще придуманы автором новости.
> p.s. по крайней мере, я бы делал именно так: это проще и
> менее накладно, чем делать подмножество c++, реализовывать aot-компиляцию с оптимизацией
> и прочую ерунду, которая производит впечатление на неискушённых и вызывает улыбку
> у тех, кто в теме.Ничего плохого и тормозного в aot нет, а вот сделать полноценную поддержку хотябы ia64 многово стоит (учтя последние наработки, например, avx), не говоря о том, что придётся переносить на всякие там arm, mips, учитывать разные виды конвейеров и кешей, поддерживать DSP на тех, же ARM-ах и тп. Ещё замечу, что вам никто не мешает явно указать какие функции какое ABI должно использовать, где распологаться в памяти и тп.
На оборот разговоры на тему "лучше наделать велосипедов -- будет быстро и просто" вызыает улыбку у тех, кто в теме.
> Ничего плохого и тормозного в aot нетдля изменяющихся условий, ага. позволь задать вопрос (не в плане унизить, просто для определения уровня беседы): ты в данном случае теоретик, или есть практика реализаций подобных штук? у меня — практика лет 10, от любительского «потому что интересно» до вполне рабочих джитеров в проектах «за бабло».
> а вот сделать полноценную поддержку хотябы ia64 многово стоит
не особо. к тому же — итаниум? just4lulz: дорого и неоправдано.
> (учтя последние наработки, например, avx)
ты, кажется, путаешь «достаточно хороший код» и «сильно оптимизированый код».
> о том, что придётся переносить на всякие там arm, mips
мипс? такую базу? зачем?
арм? с трудом, но представляю. опять же несложно.> учитывать разные виды конвейеров и кешей, поддерживать DSP на тех, же ARM-ах
> и тп.зачем? задачи «сделать супероптимальный код» не стоит, для этого есть «оффлайновые» aot-компиляторы.
> Ещё замечу, что вам никто не мешает явно указать
> какие функции какое ABI должно использовать, где распологаться в памяти и
> тп.а это тут при чём? я не понял, к чему сие было написано. поясни, плз.
> На оборот разговоры на тему "лучше наделать велосипедов — будет быстро и
> просто" вызыает улыбку у тех, кто в теме.угу, болельщики завсегда лучше спортсменов знают, как надо. только вот выступать что-то не рвутся.
p.s. мне показалось, или ты ушёл в задачу «универсальный JIT»? я ни разу не вёл речь про универсальный JIT, только про специализированный, для конкретной области применений.
>> Ничего плохого и тормозного в aot нет
> для изменяющихся условий, ага. позволь задать вопрос (не в плане унизить, просто
> для определения уровня беседы): ты в данном случае теоретик, или есть
> практика реализаций подобных штук? у меня — практика лет 10, от
> любительского «потому что интересно» до вполне рабочих джитеров в проектах «за
> бабло».Меня всегда умиляли люди с практикой под 10 лет, которые качали авторитет подобным
образом. Например, я, да и вы, наверное, просидели в школе 10 лет(если не ошибусь).
Но, я вот, так и не научился на русском грамотно писать, также можно и 10-ти
летний опыт в программировании получать.>> а вот сделать полноценную поддержку хотябы ia64 многово стоит
> не особо. к тому же — итаниум? just4lulz: дорого и неоправдано.Виноват, я имел введу AMD64 (вечно забываю про итаниум :-))
>> (учтя последние наработки, например, avx)
> ты, кажется, путаешь «достаточно хороший код» и «сильно оптимизированый
> код».Действительно, я не понимаю что вы предпологаете говоря "достаточно хороший код",
в нашем случае мы ждём от кода только две вещи: 1. быстро и 2. оптимизированно транслироваться в машинный код.>> о том, что придётся переносить на всякие там arm, mips
> мипс? такую базу? зачем?
> арм? с трудом, но представляю. опять же несложно.Думаю на desktop MemSQL может найти применение, так же как и в embedded устройствах.
>> Ещё замечу, что вам никто не мешает явно указать
>> какие функции какое ABI должно использовать, где распологаться в памяти и
>> тп.
> а это тут при чём? я не понял, к чему сие было
> написано. поясни, плз.Ну не вы ли тут говорили о том, что надо "укладывать часто вызываемые функции рядышком",
я намекнул, что это лишь вершина айзберга.>> На оборот разговоры на тему "лучше наделать велосипедов — будет быстро и
>> просто" вызыает улыбку у тех, кто в теме.
> угу, болельщики завсегда лучше спортсменов знают, как надо. только вот выступать что-то
> не рвутся.
> p.s. мне показалось, или ты ушёл в задачу «универсальный JIT»? я ни
> разу не вёл речь про универсальный JIT, только про специализированный, для
> конкретной области применений.Вам это показалось. Я говорю о том, что то эпическое количество оптимизаций который есть в любом компиляторе вы на колленке никогда не напишете, а если и напишете, то это займёт уйму времени. Проще разобраться в том, как заставить компилятор решать вашу специализированную задачу, чем писать новый недокомпилятор для неё.
а меня всегда умиляли люди, которые на вопрос о наличии практики начинают «лепить отмазки». я же специально упомянул, что не для трололо спрашиваю. или выяснять профуровень собеседника и стараться подстраиваться под его опыт и знания (чтобы беседа не превратилась в соревнование вентиляторщиков) уже немодно?> Виноват, я имел введу AMD64 (вечно забываю про итаниум :-))
а ещё это можно назвать «EM64T» и «Intel 64». %-) эту систему команд можно принять за RISC в первом приближении. x86 намного хуже и геморройней.
> Действительно, я не понимаю что вы предпологаете говоря «достаточно хороший код»,
> в нашем случае мы ждём от кода только две вещи: 1. быстро
> и 2. оптимизированно транслироваться в машинный код.понятие «оптимизировано» очень расплывчато. «достаточно хороший код» в данном случае — это код, который работает быстрее, чем, например, bytecode vm, при этом кодогенератор не становится неуправляемым тормозным монстром и генерирует код без заметных тормозов. чем больше вбухивается в код оптимизаций, тем медленее — натурально — кодоген. увлечение генераторами «оптимального кода» — интересное занятие, но оно любит сжирать время и ресурсы на непродуктивные вещи типа «добавим ещё 100500 строчек и ускорим выходной код на два такта». в большинстве случаев это совсем ненужно.
опять же, не стоит, например, оптимизировать то, что исполняется довольно редко. и ещё много всякого.
> Думаю на desktop MemSQL может найти применение, так же как и в
> embedded устройствах.база, которая требует 100500 памяти? ну, можно, конечно: вон, кдешники умудряются для хранения адресбука MySQL использовать. только вот есть варианты получше, чем брать относительно универсальный инструмент (не предназначеный, кстати, для решения подобных микрозадач) и пытаться его впихнуть туда, где он не нужен.
> Ну не вы ли тут говорили о том, что надо "укладывать часто
> вызываемые функции рядышком",
> я намекнул, что это лишь вершина айзберга.это всего лишь простая и очевидная оптимизация для шитого кода (которая, тем не менее, часто даёт заметный выигрыш; и при этом реализуется без особого труда). естественно, есть много других вариантов.
> Вам это показалось. Я говорю о том, что то эпическое количество оптимизаций
> который есть в любом компиляторе вы на колленке никогда не напишетевот. я и говорю: ушёл в задачу об «универсальном JIT». собственно, это и есть отсутствие опыта и понимания, что такое JIT, зачем оно нужно и почему иногда «worse is better».
> Проще разобраться
> в том, как заставить компилятор решать вашу специализированную задачу, чем писать
> новый недокомпилятор для неё.авторы [E]DSL-ей рвут на себе волосы: оказывается, они всё это время всё переусложняли.
Проф уровень 0, если вас так интеерсует.> x86 намного хуже и геморройней.
64 не далеко ушла от x86. Как была геморойной, так и осталась.
Да и не имеет это отношение к теме.>[оверквотинг удален]
>> в нашем случае мы ждём от кода только две вещи: 1. быстро
>> и 2. оптимизированно транслироваться в машинный код.
> понятие «оптимизировано» очень расплывчато. «достаточно хороший код»
> в данном случае — это код, который работает быстрее, чем, например,
> bytecode vm, при этом кодогенератор не становится неуправляемым тормозным монстром и
> генерирует код без заметных тормозов. чем больше вбухивается в код оптимизаций,
> тем медленее — натурально — кодоген. увлечение генераторами «оптимального
> кода» — интересное занятие, но оно любит сжирать время и ресурсы
> на непродуктивные вещи типа «добавим ещё 100500 строчек и ускорим выходной
> код на два такта». в большинстве случаев это совсем ненужно.Спасибо КЭП. Все оптимизации, те что вам не свосем нужны, можете просто взять и выключить.
> опять же, не стоит, например, оптимизировать то, что исполняется довольно редко. и
> ещё много всякого.В таком случае компиляете код без оптимизации, если выясняется что он выполняется часто, компиляете с нужной вам оптимизацией.
>> Думаю на desktop MemSQL может найти применение, так же как и в
>> embedded устройствах.
> база, которая требует 100500 памяти? ну, можно, конечно: вон, кдешники умудряются для
> хранения адресбука MySQL использовать. только вот есть варианты получше, чем брать
> относительно универсальный инструмент (не предназначеный, кстати, для решения подобных
> микрозадач) и пытаться его впихнуть туда, где он не нужен.Возможно оно и не нужно, я это лишь предположил.
>> Ну не вы ли тут говорили о том, что надо "укладывать часто
>> вызываемые функции рядышком",
>> я намекнул, что это лишь вершина айзберга.
> это всего лишь простая и очевидная оптимизация для шитого кода (которая, тем
> не менее, часто даёт заметный выигрыш; и при этом реализуется без
> особого труда). естественно, есть много других вариантов.Есть множество других простых и очевидных оптимизаций, так же как и масса очень
не простых и очень эффективных оптимизаций. Если лепить слабо понимая в теме, то
больше чем наверняка получится хуже и медленее.>> Вам это показалось. Я говорю о том, что то эпическое количество оптимизаций
>> который есть в любом компиляторе вы на колленке никогда не напишете
> вот. я и говорю: ушёл в задачу об «универсальном JIT».Вам опять это показалось.
>> Проще разобраться
>> в том, как заставить компилятор решать вашу специализированную задачу, чем писать
>> новый недокомпилятор для неё.
> авторы [E]DSL-ей рвут на себе волосы: оказывается, они всё это время всё
> переусложняли.У каждого свои мнения о том, как делать правильно. Так же, как кто-то пишет на C++ и смеётся над ADA программистами.
>> x86 намного хуже и геморройней.
> 64 не далеко ушла от x86. Как была геморойной, так и осталась.там больше регистров, и они не так жестоко прибиты гвоздями к операциям. поэтому несколько проще.
> Спасибо КЭП. Все оптимизации, те что вам не свосем нужны, можете просто
> взять и выключить.ок, если ты не можешь мыслить абстрактно, можно попробовать так: я пишу самопальный JIT-компилятор DSL, ты — используешь clang++/llvm или g++. потом сравниваем простоту поддержки/понимания исходного кода и общую скорость работы софтины на куче меняющихся скриптов. скорость разработки тоже учитываем. условия можно (и нужно) обговорить потом подробней, конечно — как кода/тестов, так и критерии выигрыша (хотя тут проще: кто быстрее, тот и папа). проиграю я — плачу тебе, например, десять тыщ USD. проиграешь ты — ты мне. натурально, без денег за игру не садимся, так что по электронному переводу с подтверждением, чтобы деньги висели, но снять нельзя было. можем привлечь независимых арбитров. может, я хоть так тебе что-то поясню (а глядишь, ещё и работника хорошего найду, чем чёрт не шутит).
натурально, такие критерии, как «документированность кода», «простота установки», «работа хотя бы под GNU/Linux и MS Windows» тоже входят.
>>> x86 намного хуже и геморройней.
>> 64 не далеко ушла от x86. Как была геморойной, так и осталась.
> там больше регистров, и они не так жестоко прибиты гвоздями к операциям.
> поэтому несколько проще.Если не брать во внимание всякие нахлабушки, регистров там столько же, только они в два раза больше. Но суть в том, что получить хороший код можно только используя всякие расширения, а это уже порядочный геморой.
>[оверквотинг удален]
> меняющихся скриптов. скорость разработки тоже учитываем. условия можно (и нужно) обговорить
> потом подробней, конечно — как кода/тестов, так и критерии выигрыша (хотя
> тут проще: кто быстрее, тот и папа). проиграю я — плачу
> тебе, например, десять тыщ USD. проиграешь ты — ты мне. натурально,
> без денег за игру не садимся, так что по электронному переводу
> с подтверждением, чтобы деньги висели, но снять нельзя было. можем привлечь
> независимых арбитров. может, я хоть так тебе что-то поясню (а глядишь,
> ещё и работника хорошего найду, чем чёрт не шутит).
> натурально, такие критерии, как «документированность кода», «простота
> установки», «работа хотя бы под GNU/Linux и MS Windows» тоже входят.Время разработки учитывать бы не стал, так как не докажешь потом, может вы там этот DSL всем отделом писали. Понимание исходного кода тоже, так как это понятие очень и очень субъективное. Да и не забывайте уровень моей компитенции 0, я по факту буду делать много дольше, чем человек с опытом.
Так что единственный критерий это скорость работы.> а глядишь, ещё и работника хорошего найду, чем чёрт не шутит
Какой работник пойдёт на вас работать, если обыграет?
> Время разработки учитывать бы не стал, так как не докажешь потом, может
> вы там этот DSL всем отделом писали.ну так и я не знаю: может, вы там тоже?
> Понимание исходного кода тоже,
> так как это понятие очень и очень субъективное.достаточно объективное, на самом деле.
> не забывайте уровень моей компитенции 0, я по факту буду делать много
> дольше, чем человек с опытом.ну и что? достаточно безапелляционные суждения ты же себе позволяешь высказывать. значит, и код сделаешь быстро и нормально, не просто же так ты высказываешься.
> Так что единственный критерий это скорость работы.
нет. очень-быстрое-нечто-понятное-только-автору нафиг не надо. «криэйторы, Вава, криэйторы, творцы нам на…й не нужны».
>> а глядишь, ещё и работника хорошего найду, чем чёрт не шутит
> Какой работник пойдёт на вас работать, если обыграет?хороший. это же не школа кунг-фу, где учитель всегда должен быть круче учеников. а зачем мне заведомо плохой работник, например, за которым мне придётся в лучшем случае переделывать, а то и переписывать?
> "генерируется C++ код" -- это сразу крест на производительности. ты прикинь, сколько времени будет выжирать вызов g++.Даже в таком случае prepared statements спасут гиганта мысли :)
Интересно какая нужна конфигурация для получения 3500рек/сек из мускула.
Только так чтобы не давно закешированый ответ а нормальное рандомное чтение из таблицы размером много больше оперативной памяти.
с какой целью интересуетесь? Имхо смысла эта информация не имеет. Если вся таблицы будут умещаться в памяти, тогда да, можно сравнить.
Оракл, десятилетней давности. Впереди большой путь по фиксации багов, добавления поддержки стандартов и, как знать, возможно через 10 лет кто-то начнет применять в промышленных условиях...
На хабре неделю назад в комментах по полочкам разобрали почему эта «самая быстрая СУБД» не нужна.
Там же ( http://habrahabr.ru/post/146023/#comment_4913015 ) выяснилось что эта _проприетарная_ разработка во всю использует код MySQL (который вроде как GPL?)
Кстати, что не характерно для хабра, разобрали довольно аргументировано.
бгг. а где аргументированней разбирают? анонимы на опеннете что ль?
они там тебе че хочешь докажут. =) Как и на лоре - ничего не нужно кроме голой консоли.
для мускуля? истинно так.
но специально для дошколят есть phpmyadmin
>MemSQL является проприетарной разработкой
>opennetТут что-то не так.
Да проприетарно и open - это несовместимо.> но распространяется бесплатно c ограничением
А вот на "freenet" вполне можно.
кажется забыли добавить подпись "НА ПРАВАХ РЕКЛАМЫ"
"""лучшее -- враг хорошего"""то есть проще говоря -- вобщемто людям не нужна "самая лучшая" СУБД. им достаточна просто ХОРОШАЯ СУБД. и уж точно не проприетарная :)
...хотя любители пирацких Фотошопов и WinRAR -- возможно заценят и эту поделку тоже... но что-то я сомниваюсь о большем успехе :)
Только потому что проприетарная разработка? Что за бред. ПО выбирается согласно задачам, а не религиозным убеждениям.
среди проприетарщины можно найти и что-то получше, чем эта "самая лучшая субд"
> Только потому что проприетарная разработка? Что за бред. ПО выбирается согласно задачам,
> а не религиозным убеждениям.и поэтому сия поделка не нужна: исходники для аудита ширнамассами недоступны, мегафич, которые бы оправдали использование никому не известного и не прошедшего широкое «боевое тестирование» irl продукта отсутствуют.
так что да: именно потому, что проприетарщина и пролетает. иначе нашлись бы энтузиасты, которые стали бы это пилить, ставить и тестировать. а так… ну, воткнуть блоб в чруте, погонять на паре игрушечных тестов и выкинуть.
> Только потому что проприетарная разработка? Что за бред.Достаточный повод чтобы обойти в новой разработке стороной. Закладываться на проприетарь сегодня - это обеспечивать себе много геморроя в будущем.
вот еще немного, совсем чуть-чуть и начнут вывешивать новости об adware...
а что, тоже бесплатно!
>Например, MemSQL не осуществляет разбор SQL на лету, вместо этого из SQL-конструкций генерируется С++ код, работающий с оптимизированными для хранения в памяти структурами данных, доступ к которым осуществляется без блокировок. Второй особенностью является то, что данные всегда полностью держатся в ОЗУ и отдаются из памяти.1. Вангую новый вид атак на сервер БД - С++-Инжекш :)
2. Как я понимаю, данные в памяти держаться до первого сбоя электроснабжения?..
Читать разучился? Написано же, синхронизируется с диском.
Читать разучился? Сказано же, что синхронизируеться не сразу, а когда нить потом, ну чтобы быстро было.
Читать разучился? Сказано же, что при коммите транзакции
>Хм. Что-то автор новости про ACID, похоже, немного загнул. memSQL обеспечивает транзакционную целостность ТОЛЬКО уровня "READ COMMITTED", и ТОЛЬКО в режиме "транзакция на SQL-запрос".Паста с коммента ниже.
Если SQL транслируется в код на С++, то можно ставить крест на динамической генерации SQL-запросов из скриптов. Или он как-то на лету транслирует, но тогда непонятно чем это от стандартного кэширования отличается.
кто-нибудь знает, что быстрее PostgreSQl или msSQL под 1с 8.2?
Для Windows - MS. Postgre медленнее и периодически встречаются глюки, когда Postgre'шники используют один механизм во всех платформах (кросс-платформенность), а в Windows данный механизм "obsolete" с приличным списком известных уязвимостей, оставленных для совместимости.Для Linux - Postgre, просто MS ещё не выпустили.
А вообще всё зависит от размера базы. Для базы меньше 10 Гб быстрее всего файловый вариант.
Для Windows - PostgreSQL. MS медленнее и периодически встречаются глюки, когда Miscrosoft-овцы баги месяцами не исправляют и давно висит приличный список неисправленных известных уязвимостей, оставленных для совместимости. Ну и лицензия на MS SQL стоит от 30 тыс рублей, но и за такие деньги поддержка нулевая, только стрелки переводят. PostgreSQL бесплатен и в форуме поддержки в течение дня на любой вопрос ответят без попыток показать клиенту, что он идиот.
>А вообще всё зависит от размера базы. Для базы меньше 10 Гб быстрее всего файловый вариант.а если база будет к примеру 4Гб, разве в файловом режиме 1с 8 будет не медленней работать по сети, чем в SQL-режиме? у меня база 1,6Гб и то уже на глаз сущетвенно заметно, что в файловом режиме намного медленней работает по сетке
Сравнение скорости работы 1С:Предприятие на MsSQL и PostrgeSQLБылинный тред.
http://www.sql.ru/forum/actualthread.aspx?tid=528465
Каков контраст первой и второй страницы.
И это при том, что 1с на постгри использует табличные блокировки, а на мссиквеле - построчные.
> И это при том, что 1с на постгри использует табличные блокировки, а
> на мссиквеле - построчные.1. Вид блокировок настраивается в PostgreSQL, а не в 1С. Она использует то, что дадут.
1. Вы о какой версии PostgreSQL говорите?
1. О сертифицированной (и патченной) в 1с
2. У 1с свой язык. Он выгребет всю таблицу в автоматических блокировках и строки в программируемых в зависимости от сервера.
3. Благодоря дизайну постгри (а теперь и оракл) всё равно уделывают мссиквел.Ещё вопросы?
Ну, эту белиберду я и так знаю. Вопрос то был про версию PostgreSQL. В современных версиях можно включить построчную блокировку. Так что, ваша информация, как бы сказать, несколько устаревшая.
Если программа говорит залочить таблицу, то сервер лочит таблицу.
И белиберда — это то, что у вас в голове.
http://www.v8.1c.ru/overview/datalockcontrol.htm
> кто-нибудь знает, что быстрее PostgreSQl или msSQL под 1с 8.2?Быстрее то, с чем умеешь и приятно работать.
У меня получается быстрее с PostgreSQl. Но я MS SQL хуже знаю.
Не показатель.
Умей в обоих, потом советуй.
Ну, похоже, PostgreSQL Вы плохо знаете, однако советуете.
Надеюсь, MS SQL Вы лучше знаете?А советовал, Я по простой причине: для плохо настроенной системы особой разницы нет и гнаться за мифических преимуществом - глупость. Лучше вложиться в изучение инструмента.
Вот и вложитесь.
А то складывается ощущение, что блокировки на строку вы только что открыли для себя в постгри и с криками вау пошли комментить всё подряд.Зыж
Оракл уже тыщу лет умеет блокировки на ячейку.
А 1с на нём всё-равно лочит всю таблицу в автомате.
>>...MemSQL является проприетарной разработкой...Дальше читать бессмысленно.
Назревает вопрос, могут ли несколько талантливых программистов за год написать полностью совместимый аналог MySQL без заимствования кода MySQL ? Нет не могут. Значит частично использовали код MySQL, но этот код под GPL, а MemSQL - проприетарщина. Вывод - имеет место нарушение GPL. Уверен, что покопавшись в потрохах их бинарников можно много пересечений с MySQL найти, которые простым обеспечением бинарной совместимости на уровне протокола не объяснить.
> Уверен, что
> покопавшись в потрохах их бинарников можно много пересечений с 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.
Выделенное жирным противоречит российскому законодательству, и любой суд признает этот пункт юридически ничтожным
Оба-на ! Ну-ка ну-ка, какому конкретно закону РФ это противоречит ?
Гражданский кодекс РФ, часть 4, статья 1280. http://www.consultant.ru/popular/gkrf4/79_2.html#p559
> Гражданский кодекс РФ, часть 4, статья 1280. http://www.consultant.ru/popular/gkrf4/79_2.html#p559Два пива этому анонимусу :). Ну или что ему там по вкусу больше.
> Гражданский кодекс РФ, часть 4, статья 1280. http://www.consultant.ru/popular/gkrf4/79_2.html#p559Впечатляет. Только как водится очень пространные и невнятные формулировки, которые можно сильно по разному трактовать. Подозреваю что если затеять тяжбу результат может оказаться не так быстр и очевиден как вы озвучили. Надо будет глянуть EULA от русской версии Windows...
> Выделенное жирным противоречит российскому законодательствуИ не только нашему, европейскому тоже - директива ЕС о правовой охране программ для ЭВМ (91/250/ЕЕС). Наша статья кстати, как говорит Крашенинников (на секундочку председатель комитета госдумы по гражданскому, уголовному, арбитражному и процессуальному законодательству, доктор юридических наук, председатель ассоциации юристов России, бывший министр юстиции Российской Федерации), так вот, наша статья написана на основе этой директивы, а в ней, ололо:
> Исключительные права автора на предотвращение несанкционированного воспроизведения должны подвергаться определенным ограничениям... действия по загрузке и прогону, необходимые для использования копии программы, которая была законно приобретена, и действие по коррекции ее ошибок не могут быть запрещены договором.
> Лицо, имеющее право использовать копию программы для ЭВМ, вправе без разрешения правообладателя изучать, исследовать или испытывать функционирование программы в целях определения идей и принципов, лежащих в основе любого элемента программы, если оно при этом осуществляет любые из действий по загрузке, воспроизведению на дисплее, прогону или запоминанию программы, которые оно вправе осуществлять.Т.е. загрузить, запустить и в результате этого исследовать программу никто запретить не может, кроме того и директива и наша статья предусматривают критерии когда программу вообще можно впрямую дизассемблировать - если это необходимо для взаимодействия с др. ПО, и договор (лицсоглашение) при этом тоже побоку.
Пруф - Постатейный комментарий глав 70-71 ГК РФ под редакцией П.В. Крашенинникова. Издание предназначено для студентов, аспирантов и преподавателей юридических вузов, судей, адвокатов, сотрудников юридических служб организаций, авторов, и т.п.
Штука новая, 2010г, возможно некоторые юристы еще не в курсе :)
У мускула двойное лицензирование
> Назревает вопрос, могут ли несколько талантливых программистов за год написать полностью
> совместимый аналог MySQL без заимствования кода MySQL ? Нет не могут.с чего бы это? документация на диалект sql открыта. интерфейсы клиента открыты. какие проблемы сделать совместимую реализацию? или ты где-то углядел в новости «совместимость по файловым форматам» и ты пы?
Кому в 2012 году может понадобиться закрытая БД без репутации в десятки лет?
> Кому в 2012 году может понадобиться закрытая БД без репутации в десятки
> лет?её авторам, которые надеются, что используя громкое имя мордокниги смогут подзашибить лавэ.
ясно. унылая ерунда, с рекламой которой прибежали на опеннет. да ещё и проприетарная, что вообще ни в какие ворота. вот зачем сюда тащить новости про всякое гуано?
> новости про всякое гуано?Вот я тоже не понимаю - зачем писать новости про всякие оперы и прочие маргинальные фигни.
(пожимает плечами) увы. никто кроме апруверов не знает, я полагаю. есть, впрочем, подозрение, что не знают даже сами апруверы.
ибо врага надо знать в лицо!
> ибо врага надо знать в лицо!это ты так намекаешь, что надо и новости о выходе очередного KB для винды сюда постить?
нет, не тот масштаб
> нет, не тот масштабв смысле — опеннет слишком мелкий для этого сайт? хм… может быть, поэтому и не постят.
в смысле KB это слишком мелкая штука, таких последствий как топик в перспективе вызвать не может.
Тьфу, кто писал заключительный абзац? Mongo, оперирующая парами "ключ-значение" - это песня.
Месье хочет, уподобившись граммар-наци, указать на вопиющую несуразность выражения "ключ-значение", тем самым повысить своё ЧСВ? Сударь, вы лох, расслабьтесь: http://www.google.co.za/search?hl=en&q=key+value+site%3...
Вы идиот.Mongo - ДОКУМЕНТНАЯ (Document-oriented) база, а ни разу не "ключ-значение". О чем и написано на первой странице сайта первым пунктом.
Так уж и быть - поясняю - в ней нет какого-то единственного ключа, по которому только и можно выдернуть хранимую сущность - а задается набор условий, которым должны удовлетворять поля документа.
> является проприетарной разработкой, но распространяется бесплатно c ограничениемПервая доза - бесплатно...
Хранить всё в памяти - много ума не надо! Ты попробуй хранить хотя бы 100 гигов, да отдавать всё быстрее пули.
Да и в целом, не таков запрос на скорость, сколь велик запрос на надёжность и защиту.
Хм. Что-то автор новости про ACID, похоже, немного загнул. memSQL обеспечивает транзакционную целостность ТОЛЬКО уровня "READ COMMITTED", и ТОЛЬКО в режиме "транзакция на SQL-запрос".