LINUX.ORG.RU

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


3

5

Доброго времени суток! Подскажите пожалуйста, как лучше хранить двумерный массив? Суть в том, что у меня в базе должны хранится карты высот. Каждая карта представляет собой двумерный массив размерностью 720*720.

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

Конечно самый простой вариант хранить данные в тексте. Но парсинг текста требует много времени. Может кто еще что посоветует?

Заранее огромное спасибо!


Ответ на: комментарий от superhackkiller1997

Есть хранишь какие-то данные, то они не меняются,

Это в твоем хайлоаде/бигдате? =)

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

А если они меняются/добавляются по 1000 записей в секунду, а читаются по 10к в секунду?

pi11 ★★★★★
()
Ответ на: комментарий от pi11

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

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

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

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

Произошел сбой сети - умерала твоя БД и то, что он заплатил до тебя не дойдёт, а если дошло, то зачем ты приплёл сюда сеть.

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

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

О5 ты приплитаешь ущербности своей ущербанскйо БДсистемы.

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

Чтение идёт из моего кеша в кеши «клиентов».

Все операции блочные.

superhackkiller1997
()
Ответ на: комментарий от pi11

Это в твоем хайлоаде/бигдате? =)

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

А если они меняются/добавляются по 1000 записей в секунду, а читаются по 10к в секунду?

Всё твоё есть блеф. Ты не можешь принимать данные быстрее твоего железячного ИО, а оно слабее твоей оперативы во много раз.

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

И да, ничего не менется - это блеф.

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

В реальном мире не нужно,

Ну да, ну да.

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

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

У каждого клиента есть локальный кеш, с которым он играется

Мощное решение, памяти не жалко? К примеру у нас 10 терабайт данных, будем их полностью в кеш для клиента загонять, чтобы потом смержить? Или частями? Может на строки разобьем? А черт, опять у тебя субд будет получаться.

я мержу его со своим кешом

Эх, хотел бы я посмотреть как у тебя код разрастется, к тому времени, когда ты все это реализуешь, и поймешь, что в любой СУБД это уже сделано, только нормально.

pi11 ★★★★★
()
Ответ на: комментарий от superhackkiller1997

И да, ничего не менется - это блеф.

Я в данном случае говорил не о структуре а о самих данных.

Ты не можешь принимать данные быстрее твоего железячного ИО, а оно слабее твоей оперативы во много раз.

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

pi11 ★★★★★
()
Ответ на: комментарий от pi11

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

Моё решение на порядки быстрее, надёжнее и проще. Этого мало?

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

Это не нужно, как я уже не однократно говорил - бесполезные блажи домохозяек и «труды» неосиляторов, которые хотят стрич домохозяек меня не интересуют.

Что такое твитер? Это мой апдейт, только блок не 720*720 флоатов, а месагасайз(который, кстати константа).

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

Потом пили юзеров и прочу байду - это пишется за пару-тройку вечерков на сишке с сотнями тонн авторизаций в секунду на одном ведре.

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

Твитер готов.

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

Это не нужно, как я уже не однократно говорил - бесполезные блажи домохозяек и «труды» неосиляторов, которые хотят стрич домохозяек меня не интересуют.

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

Это мой апдейт, только блок не 720*720 флоатов, а месагасайз(который, кстати константа).

и

У каждого клиента есть локальный кеш, с которым он играется

Да? =)

pi11 ★★★★★
()
Ответ на: комментарий от pi11

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

Никакая твоя транзакция тебе не спасёт - очередной блеф.

Мощное решение, памяти не жалко? К примеру у нас 10 терабайт данных, будем их полностью в кеш для клиента загонять, чтобы потом смержить? Или частями? Может на строки разобьем? А черт, опять у тебя субд будет получаться.

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

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

Мощное решение, памяти не жалко? К примеру у нас 10 терабайт данных, будем их полностью в кеш для клиента загонять, чтобы потом смержить? Или частями? Может на строки разобьем? А черт, опять у тебя субд будет получаться.

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

Эх, хотел бы я посмотреть как у тебя код разрастется, к тому времени, когда ты все это реализуешь, и поймешь, что в любой СУБД это уже сделано, только нормально.

Надо хранить мапы и уметь ид_то_мап - мой код умеет это за 3 строчки и быстрее на порядки твоей бд. Ты не находишь тут противоречие?

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

Это мой апдейт, только блок не 720*720 флоатов, а месагасайз(который, кстати константа).

Что такое «мой апдейт»?

pi11 ★★★★★
()
Ответ на: комментарий от pi11

А какая мне разница сколько данных, если их структура одна? Хоть мильён, хоть мильярд - оффсет он и в африке оффсет.

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

Если мне надо будет хранить ТБ - я напишу свою ФС. Да и ни с какими файлами я не запутаюсь, ибо у меня никаких файлов и нет.

Я тебе написал - структура данных одна - мне похрен сколько их и как они пишутся.

superhackkiller1997
()
Ответ на: комментарий от pi11

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

Я описал тебе как он работает - это примитивщина. Ты должен называть не бесполезные твитеры, соцсети и прочую муру, а реально полезные вещи, допустим форум-лор.

и

3 строчки - идеальный перфоманс.

Да? =)

Если нет - твоя система фуфло. С твоим перфомансом ты не сможешь отдавать 100% актуальные данные даже с сотней писателей, да хотябы с десятком.

Поэтому про актуальность можешь мне не говорить - актуальность не нужна.

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

Никакая твоя транзакция тебе не спасёт - очередной блеф.

Как ты думаешь зачем вобще транзакции нужны?

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

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

Ну давай возьмем 50гб.

У данных есть еденица данных с этими еденицами кеш и работает,

Расскажи как ты единицы будешь реализовывать, и еще расскажи про твой «мержинг» данных. Конфликты как разрешать будешь?

У тебя не может быть 10терабайт данных - ты что несёшь? У твоих клиентов 100терабитные линки?

Я же не говорил, что клиенту нужны все данные единовременно. Клиенту нужны обычно определенные данные выбранные по условиям.

мой код умеет это за 3 строчки и быстрее на порядки твоей бд. Ты не находишь тут противоречие?

Твой код умеет примерно ничего.

pi11 ★★★★★
()
Ответ на: комментарий от superhackkiller1997

Хоть мильён, хоть мильярд - оффсет он и в африке оффсет.

Т.е. уже индексы придется делать. Ок.

pi11 ★★★★★
()
Ответ на: комментарий от pi11

Если я юзаю то же, что есть в твоей БД - это не значит, что я изобретаю БД.

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

Любой мой код/идеи с вероятность 80% есть где-то в больших системах, но мои идеи и код рождались не как часть униврсальной системы и они не будет частью универсально системы НИКОГДА.

Если я копирую данные в сишке - я не изобретаю memcpy - я просто копирую данные так, как удобно мне. Хотя мемкопи это плохой пример - маллок и вообще аллокаторы памяти - вот твоя бд.

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

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

Ладно, понятно, надоело мне с тобой спорить.

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

p.s.

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

pi11 ★★★★★
()
Последнее исправление: pi11 (всего исправлений: 2)
Ответ на: комментарий от pi11

Как ты думаешь зачем вобще транзакции нужны?

Кастыль для БД. Никак не спасёт тебя от зануления ФС, падение сети до прешедших пакетов и прочее - очередной твйо блеф.

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

Мы говорим не о теории. Хранят и юзают - это разные вещи. Любая домохозяка хранит терабайты, но вот не юзает их - очередной блеф.

Расскажи как ты единицы будешь реализовывать, и еще расскажи про твой «мержинг» данных. Конфликты как разрешать будешь?

Они итак есть - в твоём твитере единица - это месага, юзер, его хранилище инфы и т.п.

Какие конфликты? У меня нет никаких конфликтов. Если 10тел поменяют что-то одно и сразу - запишется самый последний. Никаких проблем нет. Если таких нет, то просто заменяются блоки.

Я же не говорил, что клиенту нужны все данные единовременно. Клиенту нужны обычно определенные данные выбранные по условиям.

А причем тут 10тб? Ты о5 говоришь про деревенский интерпрайз и сайтики. Пили индексацию.

Твой код умеет примерно ничего.

Мой код УМЕЕТ ВСЁ, ЧТО НУЖНО, а ты балабол.

superhackkiller1997
()
Ответ на: комментарий от pi11

Ладно, понятно, надоело мне с тобой спорить.

Ты не спорил, а плавал как какаха в окиянах ненужностей.

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

Зачем мне нужны твои представления о СУБД, если они мне ну нужны и я запилю без них, не хуже, чем ты на них?

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

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

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

Реально? Ты запилишь 95% задач быстрее, чем я? Удивил. Ты запилишь их с такой же скоростью, а потом будешь оправдывать себя тем, что «аесли то, а если сё».

Терять чьё время? Возможно ты перепутал и не понимаешь зачем нужны СУБД. СУБД нужны для того, чтобы разграничить заедушный анскиллед и пропацанов, решив тем самым тотальную нехватку кадров в заедушном, бесполезном, никомуне нужному деревескому интерпрайзу.

Поэтому да, для этих личностей юзать СУБД быстрее, а нанимать этих личностей дешевле. Но мне они как-то не интересны.

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

superhackkiller1997
()

Почему вы так уверены в том, что я споря о ваших БД(etc) обязан понимать как и что вы там юзаете - я понимаю как они работают и я понимаю почему они бесполезны - мне этого хватает. Какие там есть кастыли и что вы там юзаете - мне не интересно.

Я сравниваю конкретную задачу, а не ололо. Меня не интересует дешевезна и какая-то скорость разработки. Меня не интересует балабольство об универсальности.

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

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

Вы принибрегли законами развития - вы обречены на провал, нет нет, не в мире деревенского интерпарайза, а в мире скилла.

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

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

Лень.

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

какая нахрен разница какой порядок байт?

запиши базу на MIPS, прочитай на x86. Если не учитывать порядок байт - в подобном коде будет факап - инфа 100%.

Pinkbyte ★★★★★
()
Ответ на: комментарий от superhackkiller1997

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

Как скорость отдельных процессоров коррелирует с написанием качественного кроссплатформенного кода?

Pinkbyte ★★★★★
()
Ответ на: комментарий от superhackkiller1997

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

nuff said

anonymous
()
Ответ на: комментарий от anonymous

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

superhackkiller1997
()
Ответ на: комментарий от Pinkbyte

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

superhackkiller1997
()
Ответ на: комментарий от Pinkbyte

Дак кода или данных? Ты уж определись.

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

Поэтому это лишь твоё оправдание и радужные мечты. Если уж я буду писать ядро для мипса - я напишу его для мипса так, чтобы оно работало вменяемо, а не какпапало оправдывая это тем, что «процессор тормазит».

Поэтому придирка не имеет смысла.

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

Она дампит состояние каждого елемента в file.shitindex

Функция shit_remove ничего не дампит, не ври.

anonymous
()
Ответ на: комментарий от superhackkiller1997

Как бы ты не лукавил - ты пишешь код для х86( если не пишешь изначально иного) делая его не зависимым от особенностей х86.

Ты может пишешь и так - а многие пишут под целевую платформу(тестируя в эмуляторе, например).

Поэтому придирка не имеет смысла

Опыт кроссплатформенной разработки чуется за версту :-)

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

Тестируешь ты его для галочки, чтобы он тупо работал. А зачем кому-то нужна БД, который работает на скорости 30r/s ты не думаешь.

Твоя кросплатформенность фейк.

superhackkiller1997
()
Ответ на: комментарий от anonymous

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

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

Если в твоём вымышленном мирке это там - мне тебя жаль.

superhackkiller1997
()
Ответ на: комментарий от Pinkbyte

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

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

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

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

Тестируешь ты его для галочки, чтобы он тупо работал. А зачем кому-то нужна БД, который работает на скорости 30r/s ты не думаешь.
Твоя кросплатформенность фейк.

А если мы сейчас начнем говорить не о MIPS, а о s390, допустим, ты тоже скажешь, что там тестировать не надо, потому что оно будет медленно работать? :-)

Pinkbyte ★★★★★
()
Ответ на: комментарий от superhackkiller1997

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

Понятно. Энтерпрайзом от твоих наколенных решений и не пахнет. Засим из треда удаляюсь - говорить с тем, кто не понимает очевидных вещей, бесполезно. Особенно учитывая с каким пафосом ты отрицаешь очевидные вещи, приводя абсолютно бредовые аргументы.

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

Причем тут тестировать не надо, ты пытаешься съюлить на подмене понятий.

Ты пишешь свою субд, которая актуальна сейчас ТОЛЬКО на х86. Пилить её под мипса смысла нет, ибо она там никому не нужна.

Да и вообще ты слился уже тем, что полностью зафейлился на фейле, в котором меня обвинил, ибо он небыл фейлом.

А про тестирование, нахрен ты его приплёл сюда? Я тебе говори не тестировать? Тестируй, только тестируй там, где от этого есть смысл и не балаболь на пустом месте.

superhackkiller1997
()
Ответ на: комментарий от Pinkbyte

Энтерпрайзом от твоих наколенных решений и не пахнет.

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

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

Мои аргументы логичны, чётки и неуязвимы, а вот у тебя аргументов нет.

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

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

Да не по догматам, но оно работает и я клал на твои догматы.

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

А она и не должна дампить.

Но значит эта функция не работает.

Она мешяет флаги в индексе - после этого ты не прочитаешь то, что удалил.

Выключу программу, включу заново и прочитаю.

А задампится на диск оно тогда, когда программулина прекратит работу.

Не задампится, конечно же. Кода для дампа в функции shit_remove не содержится. Еще раз - ты должен предоставить _полный_ код. Он не должен требовать дописывания в main.

Так же работает rm

Нет, не так же.

Он ничего не удаляет, ничего не дампит.

Дампит, конечно же.

Он лишь говорит фс - выпили это, фс шаманит с инодами.

Ага. И изменения в ФС сохраняются. А у тебя - не сохраняются. Поэтому rm работает, а твой shit_remove - нет.

и не на какой диск состояние иннодов фс не дампит после каждого рм.

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

anonymous
()
Ответ на: комментарий от superhackkiller1997

но у меня работает

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

anonymous
()
Ответ на: комментарий от anonymous

Тотальный слив. Иди почитай про работу ФС, раз не хватает мозгов понять всю бредовость твоего выхлопа.

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

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

superhackkiller1997
()
Ответ на: комментарий от anonymous

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

Ибо ты не осилил написать что-то и ты уже давно понял, поэтому балаболь дальше.

superhackkiller1997
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.