форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
Сообщение от opennews (??) on 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
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+6 +/–
Сообщение от Аноним (??) on 25-Июн-12, 08:53
>Высокая производительность в MemSQL достигается благодаря реализации нескольких интересных особенностей. Например, в MemSQL не осуществляет разбор SQL на лету, вместо этого из SQL-конструкций генерируется и зтем компилируется С++ код -Потенциально 10 000 уязвимостей. >MemSQL является проприетарной разработкой, - о которых вы никогда и не узнаете. Точнее узнаете, когда юные какеры будут тренироваться на базе ваших паролей.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	49. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	–2 +/–
	Сообщение от pavlinux (ok) on 25-Июн-12, 14:45
	Последний абзац конечно прочёл?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+8 +/–
Сообщение от ааноним on 25-Июн-12, 08:55
Думал действительно что-то интересное придумали, а "генерируется С++ код", "данные всегда полностью держатся в ОЗУ" как-то первое, что приходит в голову при желании добиться такой производительности.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	34. "MemSQL - претендент за звание самой быстрой СУБД,..."	–1 +/–
	Сообщение от arisu (ok) on 25-Июн-12, 13:30
	> Думал действительно что-то интересное придумали, а "генерируется С++ код", "данные всегда > полностью держатся в ОЗУ" как-то первое, что приходит в голову при > желании добиться такой производительности. "генерируется C++ код" -- это сразу крест на производительности. ты прикинь, сколько времени будет выжирать вызов g++. p.s. я понимаю, что имелась в виду скорее всего обычная JIT-компиляция (а то и просто шитый код, возможно даже не подпрограммный). но не поиздеваться над текстом новости я не мог.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	46. "MemSQL - претендент за звание самой быстрой СУБД,..."	+1 +/–
	Сообщение от FFASM (ok) on 25-Июн-12, 14:30
	Кроме g++ альтернатив нет.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	47. "MemSQL - претендент за звание самой быстрой СУБД,..."	+/–
	Сообщение от arisu (ok) on 25-Июн-12, 14:33
	> Кроме g++ альтернатив нет. да без разницы: другие не сильно быстрее, если рассматривать именно «C++ код». ведь не сказали же, что «машинный код», а именно «C++». а его надо компилировать. а поэтому надо распарзивать кучу заголовков и заниматься прочей ненужной работой.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	54. "MemSQL - претендент за звание самой быстрой СУБД,..."	+/–
	Сообщение от kurokaze (ok) on 25-Июн-12, 15:11
	>а поэтому надо распарзивать кучу заголовков Открой для себя PCH.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	58. "MemSQL - претендент за звание самой быстрой СУБД,..."	+/–
	Сообщение от arisu (ok) on 25-Июн-12, 15:29
	>>а поэтому надо распарзивать кучу заголовков > Открой для себя PCH. угу, их парзить не надо, они автомагически распарзиваются, за нулевое время.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	75. "MemSQL - претендент за звание самой быстрой СУБД,..."	+/–
	Сообщение от Аноним (??) on 25-Июн-12, 21:05
	> угу, их парзить не надо, они автомагически распарзиваются, за нулевое время. Ну я могу себе вообразить продвинутый кешинг когда c++ версия буферизуется и потом немедленно доступна при таком же запросе. Вот только если надо такие уровни производительности - это пора уже нa key-value базы смотреть, там оверхеда по определению минимум.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	55. "MemSQL - претендент за звание самой быстрой СУБД,..."	+/–
	Сообщение от FFASM (ok) on 25-Июн-12, 15:14
	>> Кроме g++ альтернатив нет. > да без разницы: другие не сильно быстрее, если рассматривать именно «C++ код». > ведь не сказали же, что «машинный код», а именно «C++». а > его надо компилировать. а поэтому надо распарзивать кучу заголовков и заниматься > прочей ненужной работой. Больше чем наверняка предпроцессором проходить вообще не придётся. Что касается C++ действительно не понятно, лучше всего (по скорости) C. Хотя может они умеют очень быстро собирать C++ или на C получается слишком муторный код, так как СУБД проще всего описать через ООП. Генерировать сразу машинный код себе дороже, будет либо не эффективно, либо почти полноценный gcc(или альтернатива) (такой же тормознутый и большой).
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	59. "MemSQL - претендент за звание самой быстрой СУБД,..."	+/–
	Сообщение от добрый дядя on 25-Июн-12, 15:31
	> Генерировать сразу машинный код себе дороже, будет либо не эффективно, либо почти полноценный gcc(или альтернатива) (такой же тормознутый и большой). man LLVM
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	61. "MemSQL - претендент за звание самой быстрой СУБД,..."	+/–
	Сообщение от arisu (ok) on 25-Июн-12, 15:36
	>> Генерировать сразу машинный код себе дороже, будет либо не эффективно, либо почти полноценный gcc(или альтернатива) (такой же тормознутый и большой). > man LLVM ну вот и «помань». а то вы, Указующие, про llvm знаете только то, что «а вот оно может!»
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	60. "MemSQL - претендент за звание самой быстрой СУБД,..."	+/–
	Сообщение от arisu (ok) on 25-Июн-12, 15:34
	> Генерировать сразу машинный код себе дороже, будет либо не эффективно, либо почти > полноценный gcc(или альтернатива) (такой же тормознутый и большой). да ни разу. даже комбинация подпрограммного шитого кода с инлайнингом в стратегических местах даст ускорение, особенно если при этом укладывать часто вызываемые функции рядышком, чтобы кэш не сильно мазал. компилятор при этом не такой и сложный получается. и шустрый. к тому же можно хранить исходную/промежуточные формы и запускать более «тяжёлые» оптимизации для запросов, которые вызывают достаточно часто. собственно, именно так и работает большинство JIT'ов. думаю, и здесь что-то подобное сделано, а слова «C++ код» или перекочевали прямиком из рекламного проспекта, или вообще придуманы автором новости. p.s. по крайней мере, я бы делал именно так: это проще и менее накладно, чем делать подмножество c++, реализовывать aot-компиляцию с оптимизацией и прочую ерунду, которая производит впечатление на неискушённых и вызывает улыбку у тех, кто в теме.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	62. "MemSQL - претендент за звание самой быстрой СУБД,..."	+/–
	Сообщение от FFASM (ok) on 25-Июн-12, 15:53
	>[оверквотинг удален] > компилятор при этом не такой и сложный получается. и шустрый. к тому > же можно хранить исходную/промежуточные формы и запускать более «тяжёлые» оптимизации > для запросов, которые вызывают достаточно часто. собственно, именно так и работает > большинство JIT'ов. > думаю, и здесь что-то подобное сделано, а слова «C++ код» или перекочевали > прямиком из рекламного проспекта, или вообще придуманы автором новости. > p.s. по крайней мере, я бы делал именно так: это проще и > менее накладно, чем делать подмножество c++, реализовывать aot-компиляцию с оптимизацией > и прочую ерунду, которая производит впечатление на неискушённых и вызывает улыбку > у тех, кто в теме. Ничего плохого и тормозного в aot нет, а вот сделать полноценную поддержку хотябы ia64 многово стоит (учтя последние наработки, например, avx), не говоря о том, что придётся переносить на всякие там arm, mips, учитывать разные виды конвейеров и кешей, поддерживать DSP на тех, же ARM-ах и тп. Ещё замечу, что вам никто не мешает явно указать какие функции какое ABI должно использовать, где распологаться в памяти и тп. На оборот разговоры на тему "лучше наделать велосипедов -- будет быстро и просто" вызыает улыбку у тех, кто в теме.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	63. "MemSQL - претендент за звание самой быстрой СУБД,..."	+/–
	Сообщение от arisu (ok) on 25-Июн-12, 16:01
	> Ничего плохого и тормозного в aot нет для изменяющихся условий, ага. позволь задать вопрос (не в плане унизить, просто для определения уровня беседы): ты в данном случае теоретик, или есть практика реализаций подобных штук? у меня — практика лет 10, от любительского «потому что интересно» до вполне рабочих джитеров в проектах «за бабло». > а вот сделать полноценную поддержку хотябы ia64 многово стоит не особо. к тому же — итаниум? just4lulz: дорого и неоправдано. > (учтя последние наработки, например, avx) ты, кажется, путаешь «достаточно хороший код» и «сильно оптимизированый код». > о том, что придётся переносить на всякие там arm, mips мипс? такую базу? зачем? арм? с трудом, но представляю. опять же несложно. > учитывать разные виды конвейеров и кешей, поддерживать DSP на тех, же ARM-ах > и тп. зачем? задачи «сделать супероптимальный код» не стоит, для этого есть «оффлайновые» aot-компиляторы. > Ещё замечу, что вам никто не мешает явно указать > какие функции какое ABI должно использовать, где распологаться в памяти и > тп. а это тут при чём? я не понял, к чему сие было написано. поясни, плз. > На оборот разговоры на тему "лучше наделать велосипедов — будет быстро и > просто" вызыает улыбку у тех, кто в теме. угу, болельщики завсегда лучше спортсменов знают, как надо. только вот выступать что-то не рвутся. p.s. мне показалось, или ты ушёл в задачу «универсальный JIT»? я ни разу не вёл речь про универсальный JIT, только про специализированный, для конкретной области применений.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	65. "MemSQL - претендент за звание самой быстрой СУБД,..."	–1 +/–
	Сообщение от FFASM (ok) on 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, только про специализированный, для > конкретной области применений. Вам это показалось. Я говорю о том, что то эпическое количество оптимизаций который есть в любом компиляторе вы на колленке никогда не напишете, а если и напишете, то это займёт уйму времени. Проще разобраться в том, как заставить компилятор решать вашу специализированную задачу, чем писать новый недокомпилятор для неё.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	67. "MemSQL - претендент за звание самой быстрой СУБД,..."	+1 +/–
	Сообщение от arisu (ok) on 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-ей рвут на себе волосы: оказывается, они всё это время всё переусложняли.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	68. "MemSQL - претендент за звание самой быстрой СУБД,..."	+/–
	Сообщение от FFASM (ok) on 25-Июн-12, 17:52
	Проф уровень 0, если вас так интеерсует. > x86 намного хуже  и геморройней. 64 не далеко ушла от x86. Как была геморойной, так и осталась. Да и не имеет это отношение к теме. >[оверквотинг удален] >> в нашем случае мы ждём от кода только две вещи: 1. быстро >> и 2. оптимизированно транслироваться в машинный код. > понятие «оптимизировано» очень расплывчато. «достаточно хороший код» > в данном случае — это код, который работает быстрее, чем, например, > bytecode vm, при этом кодогенератор не становится неуправляемым тормозным монстром и > генерирует код без заметных тормозов. чем больше вбухивается в код оптимизаций, > тем медленее — натурально — кодоген. увлечение генераторами «оптимального > кода» — интересное занятие, но оно любит сжирать время и ресурсы > на непродуктивные вещи типа «добавим ещё 100500 строчек и ускорим выходной > код на два такта». в большинстве случаев это совсем ненужно. Спасибо КЭП. Все оптимизации, те что вам не свосем нужны, можете просто взять и выключить. > опять же, не стоит, например, оптимизировать то, что исполняется довольно редко. и > ещё много всякого. В таком случае компиляете код без оптимизации, если выясняется что он выполняется часто, компиляете с нужной вам оптимизацией. >> Думаю на desktop MemSQL может найти применение, так же как и в >> embedded устройствах. > база, которая требует 100500 памяти? ну, можно, конечно: вон, кдешники умудряются для > хранения адресбука MySQL использовать. только вот есть варианты получше, чем брать > относительно универсальный инструмент (не предназначеный, кстати, для решения подобных > микрозадач) и пытаться его впихнуть туда, где он не нужен. Возможно оно и не нужно, я это лишь предположил. >> Ну не вы ли тут говорили о том, что надо "укладывать часто >> вызываемые функции рядышком", >> я намекнул, что это лишь вершина айзберга. > это всего лишь простая и очевидная оптимизация для шитого кода (которая, тем > не менее, часто даёт заметный выигрыш; и при этом реализуется без > особого труда). естественно, есть много других вариантов. Есть множество других простых и очевидных оптимизаций, так же как и масса очень не простых и очень эффективных оптимизаций. Если лепить слабо понимая в теме, то больше чем наверняка получится хуже и медленее. >> Вам это показалось. Я говорю о том, что то эпическое количество оптимизаций >> который есть в любом компиляторе вы на колленке никогда не напишете > вот. я и говорю: ушёл в задачу об «универсальном JIT». Вам опять это показалось. >> Проще разобраться >> в том, как заставить компилятор решать вашу специализированную задачу, чем писать >> новый недокомпилятор для неё. > авторы [E]DSL-ей рвут на себе волосы: оказывается, они всё это время всё > переусложняли. У каждого свои мнения о том, как делать правильно. Так же, как кто-то пишет на C++ и смеётся над ADA программистами.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	70. "MemSQL - претендент за звание самой быстрой СУБД,..."	+1 +/–
	Сообщение от arisu (ok) on 25-Июн-12, 18:20
	>> x86 намного хуже  и геморройней. > 64 не далеко ушла от x86. Как была геморойной, так и осталась. там больше регистров, и они не так жестоко прибиты гвоздями к операциям. поэтому несколько проще. > Спасибо КЭП. Все оптимизации, те что вам не свосем нужны, можете просто > взять и выключить. ок, если ты не можешь мыслить абстрактно, можно попробовать так: я пишу самопальный JIT-компилятор DSL, ты — используешь clang++/llvm или g++. потом сравниваем простоту поддержки/понимания исходного кода и общую скорость работы софтины на куче меняющихся скриптов. скорость разработки тоже учитываем. условия можно (и нужно) обговорить потом подробней, конечно — как кода/тестов, так и критерии выигрыша (хотя тут проще: кто быстрее, тот и папа). проиграю я — плачу тебе, например, десять тыщ USD. проиграешь ты — ты мне. натурально, без денег за игру не садимся, так что по электронному переводу с подтверждением, чтобы деньги висели, но снять нельзя было. можем привлечь независимых арбитров. может, я хоть так тебе что-то поясню (а глядишь, ещё и работника хорошего найду, чем чёрт не шутит). натурально, такие критерии, как «документированность кода», «простота установки», «работа хотя бы под GNU/Linux и MS Windows» тоже входят.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	71. "MemSQL - претендент за звание самой быстрой СУБД,..."	+/–
	Сообщение от FFASM (ok) on 25-Июн-12, 18:47
	>>> x86 намного хуже  и геморройней. >> 64 не далеко ушла от x86. Как была геморойной, так и осталась. > там больше регистров, и они не так жестоко прибиты гвоздями к операциям. > поэтому несколько проще. Если не брать во внимание всякие нахлабушки, регистров там столько же, только они в два раза больше. Но суть в том, что получить хороший код можно только используя всякие расширения, а это уже порядочный геморой. >[оверквотинг удален] > меняющихся скриптов. скорость разработки тоже учитываем. условия можно (и нужно) обговорить > потом подробней, конечно — как кода/тестов, так и критерии выигрыша (хотя > тут проще: кто быстрее, тот и папа). проиграю я — плачу > тебе, например, десять тыщ USD. проиграешь ты — ты мне. натурально, > без денег за игру не садимся, так что по электронному переводу > с подтверждением, чтобы деньги висели, но снять нельзя было. можем привлечь > независимых арбитров. может, я хоть так тебе что-то поясню (а глядишь, > ещё и работника хорошего найду, чем чёрт не шутит). > натурально, такие критерии, как «документированность кода», «простота > установки», «работа хотя бы под GNU/Linux и MS Windows» тоже входят. Время разработки учитывать бы не стал, так как не докажешь потом, может вы там этот DSL всем отделом писали. Понимание исходного кода тоже, так как это понятие очень и очень субъективное. Да и не забывайте уровень моей компитенции 0, я по факту буду делать много дольше, чем человек с опытом. Так что единственный критерий это скорость работы. > а глядишь, ещё и работника хорошего найду, чем чёрт не шутит Какой работник пойдёт на вас работать, если обыграет?
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	72. "MemSQL - претендент за звание самой быстрой СУБД,..."	+/–
	Сообщение от arisu (ok) on 25-Июн-12, 19:09
	> Время разработки учитывать бы не стал, так как не докажешь потом, может > вы там этот DSL всем отделом писали. ну так и я не знаю: может, вы там тоже? > Понимание исходного кода тоже, > так как это понятие очень и очень субъективное. достаточно объективное, на самом деле. > не забывайте уровень моей компитенции 0, я по факту буду делать много > дольше, чем человек с опытом. ну и что? достаточно безапелляционные суждения ты же себе позволяешь высказывать. значит, и код сделаешь быстро и нормально, не просто же так ты высказываешься. > Так что единственный критерий это скорость работы. нет. очень-быстрое-нечто-понятное-только-автору нафиг не надо. «криэйторы, Вава, криэйторы, творцы нам на…й не нужны». >> а глядишь, ещё и работника хорошего найду, чем чёрт не шутит > Какой работник пойдёт на вас работать, если обыграет? хороший. это же не школа кунг-фу, где учитель всегда должен быть круче учеников. а зачем мне заведомо плохой работник, например, за которым мне придётся в лучшем случае переделывать, а то и переписывать?
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	64. "MemSQL - претендент за звание самой быстрой СУБД,..."	+/–
	Сообщение от ыгчч on 25-Июн-12, 16:05
	> "генерируется C++ код" -- это сразу крест на производительности. ты прикинь, сколько времени будет выжирать вызов g++. Даже в таком случае prepared statements спасут гиганта мысли :)
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

5. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+3 +/–
Сообщение от o on 25-Июн-12, 09:02
Интересно какая нужна конфигурация для получения 3500рек/сек из мускула. Только так чтобы не давно закешированый ответ а нормальное рандомное чтение из таблицы размером много больше оперативной памяти.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	78. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
	Сообщение от axe (??) on 25-Июн-12, 21:43
	с какой целью интересуетесь? Имхо смысла эта информация не имеет. Если вся таблицы будут умещаться в памяти, тогда да, можно сравнить.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
Сообщение от Аноним (??) on 25-Июн-12, 09:26
Оракл, десятилетней давности. Впереди большой путь по фиксации багов, добавления поддержки стандартов и, как знать, возможно через 10 лет кто-то начнет применять в промышленных условиях...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

	11. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
	Сообщение от Челз on 25-Июн-12, 10:23
	Кстати, что не характерно для хабра, разобрали довольно аргументировано.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	29. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
	Сообщение от анон on 25-Июн-12, 12:59
	бгг. а где аргументированней разбирают? анонимы на опеннете что ль?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

10. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+1 +/–
Сообщение от Аноним (??) on 25-Июн-12, 10:10
они там тебе че хочешь докажут. =) Как и на лоре - ничего не нужно кроме голой консоли.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
	Сообщение от Куяврик on 25-Июн-12, 12:31
	для мускуля? истинно так. но специально для дошколят есть phpmyadmin
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+1 +/–
Сообщение от anonymous (??) on 25-Июн-12, 10:24
>MemSQL является проприетарной разработкой >opennet Тут что-то не так.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	40. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
	Сообщение от Андрей (??) on 25-Июн-12, 13:57
	Да проприетарно и open - это несовместимо. > но распространяется бесплатно c ограничением А вот на "freenet" вполне можно.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

13. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+3 +/–
Сообщение от Челз on 25-Июн-12, 10:24
кажется забыли добавить подпись "НА ПРАВАХ РЕКЛАМЫ"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+2 +/–
Сообщение от Xasd (ok) on 25-Июн-12, 10:24
"""лучшее -- враг хорошего""" то есть проще говоря -- вобщемто людям не нужна "самая лучшая" СУБД. им достаточна просто ХОРОШАЯ СУБД. и уж точно не проприетарная :) ...хотя любители пирацких Фотошопов и WinRAR -- возможно заценят и эту поделку тоже... но что-то я сомниваюсь о большем успехе :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	–4 +/–
	Сообщение от SubGun (ok) on 25-Июн-12, 11:20
	Только потому что проприетарная разработка? Что за бред. ПО выбирается согласно задачам, а не религиозным убеждениям.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	30. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
	Сообщение от анон on 25-Июн-12, 13:01
	среди проприетарщины можно найти и что-то получше, чем эта "самая лучшая субд"
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	36. "MemSQL - претендент за звание самой быстрой СУБД,..."	+1 +/–
	Сообщение от arisu (ok) on 25-Июн-12, 13:36
	> Только потому что проприетарная разработка? Что за бред. ПО выбирается согласно задачам, > а не религиозным убеждениям. и поэтому сия поделка не нужна: исходники для аудита ширнамассами недоступны, мегафич, которые бы оправдали использование никому не известного и не прошедшего широкое «боевое тестирование» irl продукта отсутствуют. так что да: именно потому, что проприетарщина и пролетает. иначе нашлись бы энтузиасты, которые стали бы это пилить, ставить и тестировать. а так… ну, воткнуть блоб в чруте, погонять на паре игрушечных тестов и выкинуть.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	74. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+1 +/–
	Сообщение от Аноним (??) on 25-Июн-12, 21:02
	> Только потому что проприетарная разработка? Что за бред. Достаточный повод чтобы обойти в новой разработке стороной. Закладываться на проприетарь сегодня - это обеспечивать себе много геморроя в будущем.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

15. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+1 +/–
Сообщение от Аноним (??) on 25-Июн-12, 10:33
вот еще немного, совсем чуть-чуть и начнут вывешивать новости об adware... а что, тоже бесплатно!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
Сообщение от Аноним (??) on 25-Июн-12, 10:35
>Например, MemSQL не осуществляет разбор SQL на лету, вместо этого из SQL-конструкций генерируется С++ код, работающий с оптимизированными для хранения в памяти структурами данных, доступ к которым осуществляется без блокировок. Второй особенностью является то, что данные всегда полностью держатся в ОЗУ и отдаются из памяти. 1. Вангую новый вид атак на сервер БД - С++-Инжекш :) 2. Как я понимаю, данные в памяти держаться до первого сбоя электроснабжения?..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	17. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	–2 +/–
	Сообщение от Аноним (??) on 25-Июн-12, 11:19
	Читать разучился? Написано же, синхронизируется с диском.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	52. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
	Сообщение от Аноним (??) on 25-Июн-12, 15:02
	Читать разучился? Сказано же, что синхронизируеться не сразу, а когда нить потом, ну чтобы быстро было.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	56. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
	Сообщение от анон on 25-Июн-12, 15:17
	Читать разучился? Сказано же, что при коммите транзакции
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	66. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
	Сообщение от Аноним (??) on 25-Июн-12, 16:44
	>Хм. Что-то автор новости про ACID, похоже, немного загнул. memSQL обеспечивает транзакционную целостность ТОЛЬКО уровня "READ COMMITTED", и ТОЛЬКО в режиме "транзакция на SQL-запрос". Паста с коммента ниже.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

20. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
Сообщение от Аноним (??) on 25-Июн-12, 12:00
Если SQL транслируется в код на С++, то можно ставить крест на динамической генерации SQL-запросов из скриптов. Или он как-то на лету транслирует, но тогда непонятно чем это от стандартного кэширования отличается.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	+/–
Сообщение от Аноним (??) on 25-Июн-12, 12:27
кто-нибудь знает, что быстрее PostgreSQl или msSQL под 1с 8.2?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	–1 +/–
	Сообщение от Ваня (??) on 25-Июн-12, 12:39
	Для Windows - MS. Postgre медленнее и периодически встречаются глюки, когда Postgre'шники используют один механизм во всех платформах (кросс-платформенность), а в Windows данный механизм "obsolete" с приличным списком известных уязвимостей, оставленных для совместимости. Для Linux - Postgre, просто MS ещё не выпустили. А вообще всё зависит от размера базы. Для базы меньше 10 Гб быстрее всего файловый вариант.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	28. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	+3 +/–
	Сообщение от Аноним (??) on 25-Июн-12, 12:48
	Для Windows - PostgreSQL. MS медленнее и периодически встречаются глюки, когда Miscrosoft-овцы баги месяцами не исправляют и давно висит приличный список неисправленных известных уязвимостей, оставленных для совместимости. Ну и лицензия на MS SQL стоит от 30 тыс рублей, но и за такие деньги поддержка нулевая, только стрелки переводят. PostgreSQL бесплатен и в форуме поддержки в течение дня на любой вопрос ответят без попыток показать клиенту, что он идиот.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	90. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	+/–
	Сообщение от Аноним (??) on 26-Июн-12, 10:54
	>А вообще всё зависит от размера базы. Для базы меньше 10 Гб быстрее всего файловый вариант. а если база будет к примеру 4Гб, разве в файловом режиме 1с 8 будет не медленней работать по сети, чем в SQL-режиме? у меня база 1,6Гб и то уже на глаз сущетвенно заметно, что в файловом режиме намного медленней работает по сетке
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	48. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	+/–
	Сообщение от Zensey on 25-Июн-12, 14:45
	Сравнение скорости работы 1С:Предприятие на MsSQL и PostrgeSQL Былинный тред. http://www.sql.ru/forum/actualthread.aspx?tid=528465 Каков контраст первой и второй страницы.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	57. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	+/–
	Сообщение от ананим on 25-Июн-12, 15:24
	И это при том, что 1с на постгри использует табличные блокировки, а на мссиквеле - построчные.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	77. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	+/–
	Сообщение от ffirefox on 25-Июн-12, 21:16
	> И это при том, что 1с на постгри использует табличные блокировки, а > на мссиквеле - построчные. 1. Вид блокировок настраивается в PostgreSQL, а не в 1С. Она использует то, что дадут. 1. Вы о какой версии PostgreSQL говорите?
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	81. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	+/–
	Сообщение от ананим on 26-Июн-12, 00:12
	1. О сертифицированной (и патченной) в 1с 2. У 1с свой язык. Он выгребет всю таблицу в автоматических блокировках и строки в программируемых в зависимости от сервера. 3. Благодоря дизайну постгри (а теперь и оракл) всё равно уделывают мссиквел. Ещё вопросы?
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

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

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

	76. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	+/–
	Сообщение от ffirefox on 25-Июн-12, 21:08
	> кто-нибудь знает, что быстрее PostgreSQl или msSQL под 1с 8.2? Быстрее то, с чем умеешь и приятно работать. У меня получается быстрее с PostgreSQl. Но я MS SQL хуже знаю.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	82. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	+/–
	Сообщение от ананим on 26-Июн-12, 00:15
	Не показатель. Умей в обоих, потом советуй.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	84. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	+/–
	Сообщение от ffirefox on 26-Июн-12, 01:05
	Ну, похоже, PostgreSQL Вы плохо знаете, однако советуете. Надеюсь, MS SQL Вы лучше знаете? А советовал, Я по простой причине: для плохо настроенной системы особой разницы нет и гнаться за мифических преимуществом - глупость. Лучше вложиться в изучение инструмента.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	92. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	+/–
	Сообщение от ананим on 26-Июн-12, 12:33
	Вот и вложитесь. А то складывается ощущение, что блокировки на строку вы только что открыли для себя в постгри и с криками вау пошли комментить всё подряд. Зыж Оракл уже тыщу лет умеет блокировки на ячейку. А 1с на нём всё-равно лочит всю таблицу в автомате.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

23. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	+/–
Сообщение от ILYA INDIGO (ok) on 25-Июн-12, 12:31
>>...MemSQL является проприетарной разработкой... Дальше читать бессмысленно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

	26. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
	Сообщение от Аноним (??) on 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.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	31. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+2 +/–
	Сообщение от анон on 25-Июн-12, 13:05
	Выделенное жирным противоречит российскому законодательству, и любой суд признает этот пункт юридически ничтожным
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	39. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
	Сообщение от AdVv (ok) on 25-Июн-12, 13:53
	Оба-на ! Ну-ка ну-ка, какому конкретно закону РФ это противоречит ?
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	45. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+3 +/–
	Сообщение от Аноним (??) on 25-Июн-12, 14:29
	Гражданский кодекс РФ, часть 4, статья 1280. http://www.consultant.ru/popular/gkrf4/79_2.html#p559
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	73. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
	Сообщение от Аноним (??) on 25-Июн-12, 21:01
	> Гражданский кодекс РФ, часть 4, статья 1280. http://www.consultant.ru/popular/gkrf4/79_2.html#p559 Два пива этому анонимусу :). Ну или что ему там по вкусу больше.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	89. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
	Сообщение от AdVv (ok) on 26-Июн-12, 02:26
	> Гражданский кодекс РФ, часть 4, статья 1280. http://www.consultant.ru/popular/gkrf4/79_2.html#p559 Впечатляет. Только как водится очень пространные и невнятные формулировки, которые можно сильно по разному трактовать. Подозреваю что если затеять тяжбу результат может оказаться не так быстр и очевиден как вы озвучили. Надо будет глянуть EULA от русской версии Windows...
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	85. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+/–
	Сообщение от Аноним (??) on 26-Июн-12, 01:17
	> Выделенное жирным противоречит российскому законодательству И не только нашему, европейскому тоже - директива ЕС о правовой охране программ для ЭВМ (91/250/ЕЕС). Наша статья кстати, как говорит Крашенинников (на секундочку председатель комитета госдумы по гражданскому, уголовному, арбитражному и процессуальному законодательству, доктор юридических наук, председатель ассоциации юристов России, бывший министр юстиции Российской Федерации), так вот, наша статья написана на основе этой директивы, а в ней, ололо: > Исключительные права автора на предотвращение несанкционированного воспроизведения должны подвергаться определенным ограничениям... действия по загрузке и прогону, необходимые для использования копии программы, которая была законно приобретена, и действие по коррекции ее ошибок не могут быть запрещены договором. > Лицо, имеющее право использовать копию программы для ЭВМ, вправе без разрешения правообладателя изучать, исследовать или испытывать функционирование программы в целях определения идей и принципов, лежащих в основе любого элемента программы, если оно при этом осуществляет любые из действий по загрузке, воспроизведению на дисплее, прогону или запоминанию программы, которые оно вправе осуществлять. Т.е. загрузить, запустить и в результате этого исследовать программу никто запретить не может, кроме того и директива и наша статья предусматривают критерии когда программу вообще можно впрямую дизассемблировать - если это необходимо для взаимодействия с др. ПО, и договор (лицсоглашение) при этом тоже побоку. Пруф - Постатейный комментарий глав 70-71 ГК РФ под редакцией П.В. Крашенинникова. Издание предназначено для студентов, аспирантов и преподавателей юридических вузов, судей, адвокатов, сотрудников юридических служб организаций, авторов, и т.п. Штука новая, 2010г, возможно некоторые юристы еще не в курсе :)
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	32. "MemSQL - претендент за звание самой быстрой СУБД, удовлетвор..."	+1 +/–
	Сообщение от анон on 25-Июн-12, 13:06
	У мускула двойное лицензирование
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	37. "MemSQL - претендент за звание самой быстрой СУБД,..."	+/–
	Сообщение от arisu (ok) on 25-Июн-12, 13:40
	> Назревает вопрос, могут ли несколько талантливых программистов за год написать полностью > совместимый аналог MySQL без заимствования кода MySQL ? Нет не могут. с чего бы это? документация на диалект sql открыта. интерфейсы клиента открыты. какие проблемы сделать совместимую реализацию? или ты где-то углядел в новости «совместимость по файловым форматам» и ты пы?
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

27. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	–1 +/–
Сообщение от б.б. on 25-Июн-12, 12:44
Кому в 2012 году может понадобиться закрытая БД без репутации в десятки лет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	38. "MemSQL - претендент за звание одной из самых быстрых..."	+/–
	Сообщение от arisu (ok) on 25-Июн-12, 13:42
	> Кому в 2012 году может понадобиться закрытая БД без репутации в десятки > лет? её авторам, которые надеются, что используя громкое имя мордокниги смогут подзашибить лавэ.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

33. "MemSQL - претендент за звание одной из самых быстрых..."	+/–
Сообщение от arisu (ok) on 25-Июн-12, 13:27
ясно. унылая ерунда, с рекламой которой прибежали на опеннет. да ещё и проприетарная, что вообще ни в какие ворота. вот зачем сюда тащить новости про всякое гуано?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	43. "MemSQL - претендент за звание одной из самых быстрых..."	–1 +/–
	Сообщение от Аноним (??) on 25-Июн-12, 14:12
	> новости про всякое гуано? Вот я тоже не понимаю - зачем писать новости про всякие оперы и прочие маргинальные фигни.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	44. "MemSQL - претендент за звание одной из самых быстрых..."	–1 +/–
	Сообщение от arisu (ok) on 25-Июн-12, 14:17
	(пожимает плечами) увы. никто кроме апруверов не знает, я полагаю. есть, впрочем, подозрение, что не знают даже сами апруверы.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	79. "MemSQL - претендент за звание одной из самых быстрых..."	+/–
	Сообщение от Аноним (??) on 25-Июн-12, 21:49
	ибо врага надо знать в лицо!
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	80. "MemSQL - претендент за звание одной из самых быстрых..."	+/–
	Сообщение от arisu (ok) on 25-Июн-12, 21:50
	> ибо врага надо знать в лицо! это ты так намекаешь, что надо и новости о выходе очередного KB для винды сюда постить?
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	86. "MemSQL - претендент за звание одной из самых быстрых..."	+/–
	Сообщение от Аноним (??) on 26-Июн-12, 01:57
	нет, не тот масштаб
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	87. "MemSQL - претендент за звание одной из самых быстрых..."	+/–
	Сообщение от arisu (ok) on 26-Июн-12, 01:58
	> нет, не тот масштаб в смысле — опеннет слишком мелкий для этого сайт? хм… может быть, поэтому и не постят.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	88. "MemSQL - претендент за звание одной из самых быстрых..."	+/–
	Сообщение от Аноним (??) on 26-Июн-12, 02:08
	в смысле KB это слишком мелкая штука, таких последствий как топик в перспективе вызвать не может.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

41. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	+/–
Сообщение от Crazy Alex (ok) on 25-Июн-12, 14:04
Тьфу, кто писал заключительный абзац? Mongo, оперирующая парами "ключ-значение" - это песня.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

	69. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	+/–
	Сообщение от Crazy Alex (ok) on 25-Июн-12, 18:03
	Вы идиот. Mongo - ДОКУМЕНТНАЯ (Document-oriented) база, а ни разу не "ключ-значение". О чем и написано на первой странице сайта первым пунктом. Так уж и быть - поясняю - в ней нет какого-то единственного ключа, по которому только и можно выдернуть хранимую сущность - а задается набор условий, которым должны удовлетворять поля документа.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

42. "MemSQL - претендент за звание одной из самых быстрых СУБД, у..."	+/–
Сообщение от Аноним (??) on 25-Июн-12, 14:11
> является проприетарной разработкой, но распространяется бесплатно c ограничением Первая доза - бесплатно...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема