MySQL как лучше хранить матрицу

mmap

ммап медленне моих кастылей на read/write, поэтому тут не в ммапе дело.

ммап медленне моих кастылей на read/write, поэтому тут не в ммапе дело.

по твоей логике ВСЕ медленнее что написал не ты. я конечно не влезал в особенности реализации mmap но у меня есть подозрения что при read/write таки лишнее копирование данных kernel<->user а при mmap таки банальное отображение через mmu.

А причем тут всё? Если он говорил про мой код.

У меня больше возможностей. Можешь написать простенький бенч, авось ты реально прав и я лах.

Я опять делаю shit_remove(10) и таблица остается на месте. Рабочий код будет?

У меня больше возможностей.

О каких возможностях идет речь? Ты уже второй день удаление осилить не можешь.

там выборка по значениям нафиг не уперлась

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

Я тут говорю о написании надежной программы, решающей задачу, а не о школохакинге на сишке для повышения своего ЧСВ, если че.

просто когда понадобится выбрать все матрицы у которых верхний левый угол больше 10

обязательно напиши на ЛОР, когда столкнешься с такой задачей

Че придираешься, проблема выдуманная, но суть ты понял.

А с чего она должна менятся? После shit_remove() ты её прочитать не сможешь - тебе хватит.

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

Ты очередной пхп-балабол, который своё неосиляторство прикрывает «не надёжно», хотя по объективным причинам моей кастыль надёжней.

А при чем тут смещение элемента ? Это троллинг, или ты правда не понимаешь в чем смысл выборки по значениям ?

ну вопрос в задаче - нужно выделение по элементам или не нужно. Если нужно, то {id,matrix_id,x,y,value} если не нужно, то {id,date,matrix} второй вариант переделывается в первый несложным образом, но если поэлементные значения не нужны, то первый вариант может очень сильно переусложнить задачу. Решение суперхакера тоже только озвученную задачу, но в отличии от решения с {id,date,matrix} оно расширяемо.

Балаболка, ты уже тотально слился везде, но ты продолжаешь нести хрень. То, что творится в твоей жалкой, неосиляторской башке мне не интересно. Я ради тебя потратит 30секунд своей жизни, а ты продолжаешь балаболить? Продолжай - мне похрен.

ко-ко-ко

Ну что я, в общем то, и предполагал: контраргументов нет. Только обвинения в неосиляторстве и убогости SQlite (ты явно не знаешь что такое качественный, параноидальный код, достаточно посмотреть на процедуру тестирования релизов SQlite, если интересно), а также уверенность в своей непогрешимости и идеальности своих школохаков, удачи.

А в чем суть расширяемости ? В уровне контроля ? Да и вариант с {id,matrix_id,x,y,value} задачу не так уж и усложняет: достаточно сделать функцию преобразования {id,matrix_id,x,y,value} во внутреннее представление матрицы и обратно. Остальное уже в памяти внутри программы.

у тебя таблица будет на порядок больше и данные не локализованы, т.е. вся надежда на индексы и кеши, но индексы будут весить ммм.. сравнимо с данными, а кеши это кеши, я не знаю можно ли на них надеяться. В том случае если тебе не нужны операции на уровне ячеек этот шаг лишний. А расширяемость имеется ввиду действия, которые нужно предпринять с случае изменения усложнения ТЗ, например вариант мегахаккера хороший в том случае, если у нас 64битая система, С-совместимый рантайм, и есть одно и только одно добавление в день, тогда его вариант очень эффективен. Но при доп. требованиях: удаление, не каждый день, другой рантайм, кеширование последнего запроса, его решение нужно доделывать, а при неудачной последовательности усложнений - переделывать. В отличии от этого вариант с DB (любой) легко позволит улучшить функционал, а в случае проседания по скорости будет видно, что надо оптимизировать и будет готов интерфейс для тестирования, как-то так.

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

да.. в общем-то попробую повториться, его решение имеет место быть, но или с подробным описанием границ области применения или после подробного выяснения у ТС, почему у него в задаче указана БД и анализа этой информации.

в чем конкретно проблема?

Запусти свой код(не изменяя) на архитектуре с другим порядком байт(на MIPS, например). Как словишь факап - приходи...

ты чо он даже x86 поддерживать отказывается, а ты про MIPS/

Запусти свою бд на мипсе - я поржу как ты получишь 30r/s.

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

Я тебе сказал - скулайт менее надёжен, тормазнее и ущербней моих 3-х строк - это объективный факт. Причем не на какие-то проценты, а на порядки.

А твои детсадовские сливы смешны - не ты слился первый в этой теме, не ты сольёшься последний. Таких балаболов тут было мильён и будет всегда, ибо вам надо оправдывать своё жалкое существование НЕ СВОИМ КОДОМ. ФУ.

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

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

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

Твой скулайт ограничен своей ущербанской природой и является кастылём для неосиляторов и не более.

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

И да, какая нахрен разница какой порядок байт? Ты запишешь последний/первым байт первым и прочитаешь первым - это не принципиально. Это дампит память и какой там порядок не имеет значения.

пикрелейтед

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

А ну хотя давай я тебе объясню, авось поймёшь и не будешь оправдывать свой детский слив моим «троллингом».

Мой код зависит только от сискола и фс. Твой скулайт зависит от сискола, фс, своего кода и твоим юзом его апи.

Сисколы и фс самые надёжные, плюс от них зависят оба решения.

А вот код скулайта( как бы там не вонял, что он идеальный - он по определению может содержать фейлы, которые мой код по определию содержать не может, ибо кода нет).

А уж код на скуйлайт апи в твоей породии на ЯП + его малонадёжный рантайм самое малонадёжное место в этой системе.

По всем объективным причинам мой код надёжней, ибо его нет. Твой код самая ненадёжная вещь в мире по определению.

которые мой код по определию содержать не может, ибо кода нет

в точку

твоим кодом можно делать сложные выборки из базы?

Выборки из базы нужны неосиляторам, мне не нужны твои выборки и твоя база.

И давай, как ты будешь выбирать что-то из 3-х миллиардов флоатов - удиви.

select * from table1 where float_field>10;

ваш код пожалуйста

Выборки из базы нужны неосиляторам, мне не нужны твои выборки и твоя база.

Какое безаппеляционное утверждение.

И будешь ждать запроса 5минут? Удивил.

Чего код?

Абсалютное утверждение. Я сам запилю себе индекс и сам буду искать то, что мне нужно, хотя на самом деле оно не нужно и 95% неосиляторов юзают БД как дампящийся на диск хешмассив.

Выборки из базы нужны неосиляторам, мне не нужны твои выборки и твоя база.
И давай, как ты будешь выбирать что-то из 3-х миллиардов флоатов - удиви.

ответ:

select * from table1 where float_field>10;

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

ваш код пожалуйста

Я тебя спросил, балабол, ты будешь ждать ответа 5минут?

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

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

Сразу видно, что ты с большими приложениями не работал. Для всех данных обработку вручную писать - то сложное приложение ты будешь писать в 10-100 раз дольше чем с базой.

А уж когда изменения структуры пойдут... Когда тебе надо будет сложные апдейты запускать. Следить за целостностью. Ууу. Я даже представить боюсь какие баги у тебя вылезут.

Тебе придется в конечном итоге свою БД писать под задачу, а это очень редко оправдано.

Я тебя спросил, балабол, ты будешь ждать ответа 5минут?

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

Большое приложение? Это какое? Деревенский интерпрайз мне не интересен и их проблемы меня не интересуют.

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

С чего должны быть какие-то изменения структуры? За целостностью чего?

Которые я напишу за те же 3секунды. Только вот потом ему надо будет ещё написать обработчик выхлопа его БДапи, которое по строчкам будет занимать куда больше моих.

Ему надо написать хранилку для флоатов строчек на 100 и того тотальный слив по всем параметрам.

В реальной бигдате, хайлоаде

И над какими же бигдата и хайлоад проектами ты работал?

С чего должны быть какие-то изменения структуры?

А почему нет?

За целостностью чего?

За целостностью данных. Даже если у тебя все данные хранятся денормализованно, как минимум нужно обрабатывать сбои, совместный доступ и т.д.

Которые я напишу за те же 3секунды.

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

Только вот потом ему надо будет ещё написать обработчик выхлопа его БДапи

Чтобы просто данные посмотреть - не нужно.

которое по строчкам будет занимать куда больше моих.

Это очень спорно.

Деревенский интерпрайз мне не интересен и их проблемы меня не интересуют

Интересует это тебя или нет, это есть. Например посмотри моделирование нефтянных месторождений.

иных больших и сложны приложениях никакие твои «сложные»

В иных, это каких?

И над какими же бигдата и хайлоад проектами ты работал?

Съехал.

А почему нет?

Изменения структуры - это аля сегодня зайфигачиили такой индекс - завтра для пускания пули для домохозяек мы запилим ещё одну киллерфичу запилив в БД ещё пару таблиц и индексов.

Только вот зачем мне это нужно - я не знаю.

За целостностью данных. Даже если у тебя все данные хранятся денормализованно, как минимум нужно обрабатывать сбои, совместный доступ и т.д.

Ну давай я тебе объясню - сбои уровня железа и ФС ты не обработаешь никак. Сбои твоей БД - это проблема твоей БД, а не моя.

И тебе я объясню - смысла в совместном доступе нет, ибо это ИО. Хоть тысячи совместных доступов запили это будет медленне мононитной очереди.

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

У реальных пацанов одно ведро, которое лишь в 50% пишит в кернелмоде может выдавать такое кол-во данных, которые не осилит записать и прочитать никакое железячное ИО.

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

И да, мне без разницы есть это или нет. 90% проблем которые они решают - проблемы вызванные их анскильностью, не более.

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

Юзать сложный поиск по миллиардам флоатов - дебилизм и не нужен в реальном мире и таких приморов куча.

А обычная индексация пишется за 5минут.

Изменения структуры - это аля сегодня зайфигачиили такой индекс

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

Ну давай я тебе объясню - сбои уровня железа и ФС ты не обработаешь никак.

Смотря что считать обработкой. Вот тебе самый популярный пример. Клиент совершает покупку в интернет магазине, заплатил - тебе нужно сохранить информацию о том, что он заплатил, тут происходит сбой сети/фс чего угодно. Что ты будешь делать? (сейчас ты наверное сольешься, сказав, что это лохов).

И тебе я объясню - смысла в совместном доступе нет, ибо это ИО. Хоть тысячи совместных доступов запили это будет медленне мононитной очереди.

Ну вот у тебя массив данных (допустим несколько миллионов записей), 10 клиентов пишут данные в этот массив (в разные места), еще 100 читают. Расскажи как ты это будешь реализовывать?

И да, мне без разницы есть это или нет. 90% проблем которые они решают - проблемы вызванные их анскильностью, не более.

Да на сколько я понял, все что не подходит под твое решение - все анскильно.

Давай на конкретных примерах разберем. Раз уж ты упомянул хайлоад. Возьмем тот же твиттер. Мне уже смешно становится, но расскажи в двух словах как бы ты его реализовал «на файлах».