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

потенциально, может доставить проблем.

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

А если одну карту рассматривать как строку длиной 720*720*sizeof(float)? А дальше пусть клиент разибрается.

Без меня совсем тут от рук отбились - его решение какаха, как и твоё.

Зачем нужен ущербанский, тормазной скулайт, когда запиливается файл на 5гигов, зануляется и юзается lseek'ом и read'ом. Хватит на 10к записей, моментальный доступ к любым данным, 0 фрагментации - лёгкий апдейт. Нинадо парсить ущербанский выхлоп какахоподелия и т.п.

Зачем нужен ущербанский, тормазной скулайт, когда запиливается файл на 5гигов, зануляется и юзается lseek'ом и read'ом.

Давай тесты (генератор данных + два варианта (read и sqlite)) для сравнения или заканчивай портить воздух.

1) не ресайзится часто, да не будет.

3) Велосипед щит, тормазной кусок какахи. Как я люблю эти создавалки мильёнов файлов из-за банального неосиляторства lseek( я надеюсь в этой породии на ЯП есть вменяемое апи к сисколам?).

Ваше посты радуют мои глаза.

Валяй мне реализацию на скулайте - я выкачу реализацию на сишке. Я не обязан копаться в твоих фекалоидных поделиях.

Осилил бы ты матчасть - ты бы со мной не спорил, а так да - вы мастера поспорить. Запомни: Нет ничего быстрее дампа сишкамассива, а потом его read() по определению.

Поэтому максимум, что может твой скулайт - это иметь такую же шустрость, но он её не имеет по определению.

Запомни: Нет ничего быстрее дампа сишкамассива, а потом его read() по определению.

Код в студию (C array + C sqlite). Нет кода - нет разговора.

Валяй мне реализацию на скулайте - я выкачу реализацию на сишке.

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

Ой как ты слился, как слился. Я сказал - твой скулайт шлак - ты не согласился, ты обязан выкатить реализацию на скулайте, либо замолкнуть и не спорить со мной.

Я даже дам тебе 20% фору как пхписту.

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

Я даже дам тебе 20% фору как пхписту.

Не пишу на PHP, не занимаюсь Web вообще.

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

Для начала выкати хоть что-нибудь.

Сливалочка, так и запишем.

[id], [matrix_id], [X], [Y], [value]

я бы расширил структуру как то так:

matrix: [id], [matrix];
matrix_revisions: [id], [matrix_id], [revision], [created], [updated];
matrix_revision_data: [id], [matrix_revision_id], [x], [y], [value];

#define MY_MAP_SIZEOF 720*720*sizeof(float)
float * global_my_map;
int global_fd;
uint64_t update(uint64_t i) {
  return (lseek(global_fd, (i * MY_MAP_SIZEOF), SEEK_SET) == (i * MY_MAP_SIZEOF)) && (read(global_fd, global_my_map, MY_MAP_SIZEOF) == MY_MAP_SIZEOF);
}

int main(void) {
   global_my_map = mmap(NULL, MY_MAP_SIZEOF, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS , 0, 0);
   global_fd = open("test.mapdump", O_RDONLY);
   update(0);
}

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

не забудь что есть LE и BE.

Распарси.

Выборку напиши. Замерять время компиляции предлагаешь?

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

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

есть LE и BE.

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

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

Как я люблю эти создавалки мильёнов файлов из-за банального неосиляторства lseek.

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

я надеюсь в этой породии на ЯП есть вменяемое апи к сисколам?

Сразу видно вопрос прафесианала.

Блин, ну напиши свой тест - я напишу тебе его для моего примера, в чём проблема?

Этот кусок итак делает ВСЁ, что нужно, а что нужно тебе - я не знаю.

Есть 5к карт 720*720. Надо уметь читать любую карту из этих 5к. Код это умеет? Умеет. Давай запилим тест, аля «прочитать карту, инкрементировать значение на 1 и записать обратно», либо что хочешь.

Реально? Мне что-то мешает удалить старые записи или обновить базу? Удиви меня.

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

Очередной балабольский слив.

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

google byte ordering

Этот кусок итак делает ВСЁ, что нужно, а что нужно тебе - я не знаю.

Окей. Давай такой список:

1) Прочитать карту. Подсчитать сумму элементов карты. Так для 100 карт с рандомным номером.

2) Прочитать карту. Изменить в ней значения 10 случайных элементов. Записать карту обратно. Так для 100 карт с рандомным номером.

3) Поменять местами 100 пар случайных карт.

Ничего не понял и не нагуглил, в чем конкретно проблема?

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

Скорее всего :) Но конкретные числа мне вёравно интересно увидеть.

1) Прочитать карту. Подсчитать сумму элементов карты. Так для 100 карт с рандомным номером.

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

2) Прочитать карту. Изменить в ней значения 10 случайных элементов. Записать карту обратно. Так для 100 карт с рандомным номером.

Зачем это нужно? Если это абсалютно не нужно в данном контексте. Да и о5 случайность тоже не особо имеет смысл.

3) Поменять местами 100 пар случайных карт.

Зачем мне менять карты, если проще менять ид, да и по контексту это не нужно.

Я даже согласен реализовать эти на 95% бесполезные тесты. Покажи мне их для скулайта.

Покажи мне их для скулайта.

Как только напишу их на C, который не видео несколько лет - так сразу. Писать это всё на Java, которую я обычно юзаю смысла нету, т.к. будет оверхед из-за JVM.

Давай, супермен, действуй. Покажи нам:

1) код который удаляет самую старую запись и добавляет новую.

2) покажи нам функцию которая из даты вычисляет нужное смещение в базе, либо говорит что таких данных нет.

Впрочем, дай угадаю, кода мы не увидим.

Зачем мне менять карты, если проще менять ид

Как ты будешь менять id, если id у тебя - это смещение в файле?

1) Самая старая запись имеет самый большой ид, да и зачем это в данном контексте.

2) Дата - это набор дней от определённой даты, я думаю ты сможешь осилить как построить на этом индекс.

3-х гигов нулей тебя хватит на 10лет, поэтому. Ах ну да, ещё есть такая штука - индексация - ты можешь запилить второй файлец, который у тебя будет хранить массивчик data_to_id, который замёт метра 2 на 100лет.

Ид же сопоставляется у ТС'а с чем-то нужным ему(зоной или т.п.), поэтому я могу спокойно менять ид, да даже если не менять - read/rwite рективны.

я думаю ты сможешь осилить как построить на этом индекс.

второй файлец, который у тебя будет хранить массивчик data_to_id, который замёт метра 2 на 100лет.

Да ты просто гений инженерных решений.

Напомни-ка мне, чем тебе 5тыщ файлов не угодили? Ну, кроме субъектива аля «это не круто». Это, кстати, позволит без гемора делать бэкапы бОльшинством утилит.

Да ты просто гений инженерных решений.

ну он немного не дотянул до .dbf/.ndx, а так - вполне нормальное решение, если будет толково реализовано

Да, это не круто. Просто не круто - мне этого хватает + тормазит. А так делай что хочешь, если тебе это удобно, но не приписывай своему решению плюсы, которых нет.

а так - вполне нормальное решение, если будет толково реализовано

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

3). и решает задачу: нужно расширить одну из матриц в середине

тут вообще данное решение превращается в адекдот.

1) Самая старая запись имеет самый большой ид, да и зачем это в данном контексте.

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

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

бывают задачи, когда это имеет смысл, особенно, если нужны свои «умные» индексы, но в данном случае согласен - ТС вполне хватит sqlite + blob

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

+ тормазит.

Диванный теоретик детектед. Только что запустил тест по последовательному открытию 5000 файлов, отработало мгновенно.

если нужны свои «умные» индексы

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

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

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

в каком виде хранились связи?

Зачем удалять старую запись? Очередные диванные неосиляторы в треде?

Какой захочешь - такой и будет - это не принципально.

Уадения(данных) НЕТ НИГДЕ, запомни это раз и на всегда. В реальном мире есть ТОЛЬКО перезапись. Удаление на уровне твоей апи, которым ты мыслишь - это махинации с индексами, которые к ХРАНЕНИЮ ДАННЫХ ОТСНОШЕНИЯ НЕ ИМЕЮТ.

в каком виде хранились связи?

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

против MySQL прирост был больше чем на порядок

а с чем-нибудь ещё сравнивали?

Зачем удалять старую запись? Очередные диванные неосиляторы в треде?

Надо! Например: экономить место или эта запись оказалось неверной и её надо удалить.

Уадения(данных) НЕТ НИГДЕ, запомни это раз и на всегда. В реальном мире есть ТОЛЬКО перезапись. Удаление на уровне твоей апи, которым ты мыслишь - это махинации с индексами, которые к ХРАНЕНИЮ ДАННЫХ ОТСНОШЕНИЯ НЕ ИМЕЮТ.

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

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

Ты не стесняйся пиши все как есть bottleneck-и где данные реально будут удаляться где нет, как будет происходить борьба с дефрагментацией. Что будет делаться с индексным файлом. А я подожду когда твоё решение превратится в переусложненный недо sqlite

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

И что в итоге? У тебя оверхед чуть ли не пол десятых доли секунды на прогетых 5к файлов. А это уже потолок 50к пустых запросов.

Выше мышление на уровне «мнгновенно не мнгновенно», не более. А то, что ты получаешь 50% оверхеда - тебя не волнует.

И это только прогретые, созданные файлы - ты же их собрался удалять - этим ты и 20% моего перфоманса не получишь. Пусть это будет одинакого мнгновенно для тебя(десятые вс сотые доли секунды), но ты получишь своей фейл рано или позно с таким подходом.

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

АХаха, очередная балаболка. Какое место, чего экномить? Ты что несёшь?

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

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

Я не собираюсь ни с чем знакомится, когда твоя бд даст мне хотябы 60% перфоманса того куска, который я дал выше(задача: есть 5к карт - надо читать их с харда по ид) - тогда в твоём балабольстве есть смысл.

А пока ты очередная интерпрайз балаболка, которая верит в какие-то БД и максимум, что осилила - пхп+какую-нибудь жаву и нихрена не знает об устройстве ФС, даннохранилищь, ОС и прочего.

Чего решение? У тебя есть 5к карт - надо удалить последнюю - перестроил индекс - последний оффсет доступен для перезаписи новой. Так это запилено во всех твоих БД, но ты даже это не осилил.

У меня ничего не будет удалятся, у меня ничего не будет добавлятся, у меня не будет фрагментации, но ты же жалкий балабол - тебе это не ведомо. А если ТС'у понадобится 10к карт - он занулит ещё пару гиг и будет ему счастье.