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

а зачем на шаред хостинге читать все данные единовременно в память?

Можно вспоминать, как MySQL валиться в ряде задач и начинают использовать иные технологии, которые конечно, как бы, признаны и там уже петросяния молчит (тот же Redis или любой другой NoSQL).

а зачем на шаред хостинге читать все данные единовременно в память?

Единовременно их в ограниченных условиях не прочесть. Я говорил о последовательном чтении по пол-миллиона записей.

Единовременно их в ограниченных условиях не прочесть. Я говорил о последовательном чтении по пол-миллиона записей.

почему пол миллиона, почему не по 529 штук?

И причём задачи, которые решает тот же редис, вполне себе не изощрённые, к примеру статистика в хайлоаде.

Можно вспоминать, как MySQL валиться в ряде задач и начинают использовать иные технологии, которые конечно, как бы, признаны и там уже петросяния молчит (тот же Redis или любой другой NoSQL).

Я удерживался как мог, но всё же спрошу. Вы не подвергались в детстве насилию со стороны MySQL?

почему пол миллиона, почему не по 529 штук?

Если читать по 529 штук 50 000 000 записей, то будут идти неоправданные затраты ресурсов на чтение запись файлов. Это всё равно, что инсертить 50 000 000 записей в MySQL отдельными запросами, против инсерта 100 запросами по полмиллиона записей, что будет несравнимо быстрее.

Я удерживался как мог, но всё же спрошу. Вы не подвергались в детстве насилию со стороны MySQL?

А это как? Я просто не в курсе, может и было, но не заметил.

А, ну замечательно. Желание доказывать неэффективность MySQL выглядит как что-то личное.

А, ну замечательно. Желание доказывать неэффективность MySQL выглядит как что-то личное.

Кто тут доказывает неэффективность MySQL? Я сравнил просто сравнил выборку через массивы и MySQL. И выборка через массив и через MySQL были не оптимизированы (в лоб). MySQL не догнал. Мне жаль кстати и я за него немного переживаю)))

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

да такая же.

Если читать по 529 штук 50 000 000 записей, то будут идти неоправданные затраты ресурсов на чтение запись файлов. Это всё равно, что инсертить 50 000 000 записей в MySQL отдельными запросами, против инсерта 100 запросами по полмиллиона записей, что будет несравнимо быстрее.

какой глупенький попался, а что если в память влезает ровно 529 записей? out of memory ловить???

ну может, я по слухам ориентируюсь

какой глупенький попался, а что если в память влезает ровно 529 записей? out of memory ловить???

Если будет out of memmory на 529, то, боюсь, в таких условиях MySQL работать не станет. Но если таки станет, то в рамках той же теоретической задачи он проиграет массивам.

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

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

Если будет out of memmory на 529, то, боюсь, в таких условиях MySQL работать не станет. Но если таки станет, то в рамках той же теоретической задачи он проиграет массивам.

это по какой причине mysql не станет работать?

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

я конечно извиняюсь. но со стороны выглядит весь тред как "массивы заебись, мускл говно, и вообще в хайлоаде юзайте массивы"

вот и мнение такое у всех почти

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

если бы спросил это меня, я бы посоветовал не заниматься фигней, а взять уже новую задачу и идти работать ;) это как автофила спросить на сколько быстрее болид ф1 набирает сотку по сравнению с внедорожником... информация настолько бесполезная... что я не знаю

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

вот и мнение такое у всех почти

+1, только хайлода нет, а есть полное отрицание ООП

это по какой причине mysql не станет работать?

Если мы говорим о голом пхп скрипте, в рамках некоторого хостинга, на котором есть проблема в этом скрипте выделить память для 529 записей типа целое-число => строка, то это значит, что есть ограничения по используемой оперативной памяти. Вполне вероятно, если инстанцировать объект MySQLi памяти может не хватить. Но если даже хватит, и если сравнить обработку 529 элементов массива против обработки 529 записей в MySQL то массивы выиграют.

я конечно извиняюсь. но со стороны выглядит весь тред как "массивы заебись, мускл говно, и вообще в хайлоаде юзайте массивы"

Я нигде никаких громких выводов не делал, проблема исключительно в местной петросянии, которая присвоила мне эти выводы.

что имеется в виду под "обработкой массива"?

пробежаться по нему?

что имеется в виду под "обработкой массива"?

Писал выше. Перебор элементов и сравнение strpos

+1, только хайлода нет, а есть полное отрицание ООП

где ты увидел полное отрицание ООП ??? )))))) хуатит!))))

а скорость команды grep замеряли? может нафиг те массивы ?

Возможно, глупости это всё, до чего ты не дошёл. Такое бывает. Я к примеру, не очень понимаю, зачем во все задачи тащат ООП даже уровня Hello World. Возможно, потому, что им типа-гуру нашёптывают, что ООП это вот всё. Но при этом моё ЧСВ в подобных ситуациях не страдает от такого - пропущу, не стану читать. Попробуй.

в общем спасибо, что рассказал нам, что a < a + b где a и b > 0

в общем спасибо, что рассказал нам, что a < a + b где a и b > 0

Я прост сделал 1 безобидный тестик, в котором показал насколько b больше.

Возможно, глупости это всё, до чего ты не дошёл. Такое бывает. Я к примеру, не очень понимаю, зачем во все задачи тащат ООП даже уровня Hello World. Возможно, потому, что им типа-гуру нашёптывают, что ООП это вот всё. Но при этом моё ЧСВ в подобных ситуациях не страдает от такого - пропущу, не стану читать. Попробуй.

Уймись )) тут нет отрицания ООП и MySQL )))

это совершенно ненужная информация, ибо b слабо зависит от а

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

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

Я нигде никаких громких выводов не делал, проблема исключительно в местной петросянии, которая присвоила мне эти выводы.

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

Уймись )) тут нет отрицания ООП и MySQL )))

Так точно Капитан Очевидность!

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

Как минимум никто не может мне привести мои слова ввиде цитат, где я утверждаю, что MySQL пора менять на массивы ))

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

ну у меня хоть ник позволяет, но остальные то как могли??? )))

Как минимум никто не может мне привести мои слова ввиде цитат, где я утверждаю, что MySQL пора менять на массивы ))

хорош соскакивать!

хорош соскакивать!

уймисссььь ))) никто не соскакивает )))

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

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

Массивы против MySQL. Провёл тестирование. Взял 50 000 000 пар ЦЕЛОЧИСЛЕННЫЙ_ИДЕНТИФИКАТОР = НЕКОТОРАЯ СЛУЧАЙНАЯ СТРОКА.

прочитал наконец в чем заключался тест ? возник вопрос: а зачем тут массивы?

интересно там хотя бы индекс 1 стоял на таблице?!

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

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

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

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

Мне сколько раз повторить, что можно оптимизировать обе стороны, но всё равно проиграет MySQL в любом случае? Использование файлов и поиск по ним, вероятнее, будет быстрее, чем массивы и соот-но MySQL. Но мы теряем в управляемости данными - в массивах она лучше, чем в обычном файле, типа csv (к примеру). Массивы можно оптимизировать, делая индекс для них.

управляемость - это что? бред. Индексы делаются для всего, для файлов тоже. Утверждение, что проиграет всегда MySQL - совершенно безосновательное утверждение от человека, который “пренебрег конкурентностью на операциях чтения”…

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

Ну вот такой вопрос тебе, что если бы эффективность использования оказалась на 50% выше у массивов. Меня бы это очень сильно заинтересовало и я бы задумался, а чего MySQL такой в край тормознутый, что массивы шустрее на 50% пусть даже в таком тесте ради теста = теста в вакууме? Я получил цифру в 20% тоже существенна, хотя не настолько, чтобы сильно париться, ведь есть оптимизация да и это не более чем один непонятный тест.

Я бы не задумывался, ибо я знаю, какие огромные затраты у mysql на разбор запросов, сериализацию ответов и сеть по передаче онных в клиент

и при меньшем числе данных эффективность файлов может быть и больше 50%

Пример приблизительно из этой же области. Если ввести в поиске ВК одну букву "п", то как минимум у меня выдаёт 14300 людей. Если фамилию Петров, то 864 000 с мелочью. Почему? Что это? баг или фича? или неправильная работа MySQL? или кеша? или разрабы увлеклись ООП? или срать на производительность и эффективность? или может глюк браузера на фоне использования локал-сторэдж?

Возможно, глупости это всё, до чего ты не дошёл. Такое бывает. Я к примеру, не очень понимаю, зачем во все задачи тащат ООП даже уровня Hello World. Возможно, потому, что им типа-гуру нашёптывают, что ООП это вот всё. Но при этом моё ЧСВ в подобных ситуациях не страдает от такого - пропущу, не стану читать. Попробуй.

но тут он прав

Пример приблизительно из этой же области. Если ввести в поиске ВК одну букву "п", то как минимум у меня выдаёт 14300 людей. Если фамилию Петров, то 864 000 с мелочью. Почему? Что это? баг или фича? или неправильная работа MySQL? или кеша? или разрабы увлеклись ООП? или срать на производительность и эффективность? или может глюк браузера на фоне использования локал-сторэдж?

привет человек мем

Ну вот такой вопрос тебе, что если бы эффективность использования оказалась на 50% выше у массивов. Меня бы это очень сильно заинтересовало и я бы задумался, а чего MySQL такой в край тормознутый, что массивы шустрее на 50% пусть даже в таком тесте ради теста = теста в вакууме? Я получил цифру в 20% тоже существенна, хотя не настолько, чтобы сильно париться, ведь есть оптимизация да и это не более чем один непонятный тест.

пиши докер тест хорош уже кекать

я конечно извиняюсь. но со стороны выглядит весь тред как "массивы заебись, мускл говно, и вообще в хайлоаде юзайте массивы"

он вообьщето изначально сказал обратное )

Артур, индексировать можно и массивы. Проверял да, лайком. Но и значения массива можно сравнивать не только strpos'ом. Факт в том, что эксперимент относительно чистый с использованием стандартного инструментария, так скажем.

эксперемент с неправильным использованием mysql? попробуй инмемори движок тогда

у mysql

а еще лучше поисковой движок

но как только дело дойдет до реального «дела» индекс в бд повесить даже джун сможет

но тут он прав

чем?

ооп ради ооп везде не нужен

ооп ради ооп везде не нужен

причем тут ооп ради ооп, даже простой hello world очень просто написать в стиле OOP с использованием SOLID и других вещей которые позволяеют писать код разумно

а главное дальше с этим кодом можно будет продолжать рабортать

так хэлаворд штука обучающая

ERROR: S client not available

а ооп везде не нужен

угу… к сожадению большинство проектов развивается по принципу “да лан, тут скрипт не сложнее хелло ворлд”, “ну ок, тут это немного добавим, тут это”… а потом сидят программисты с десятками мегабайт монолита и боятся что-то рефакторить, ибо не понятно где что отвалится

рилтолк

угу… к сожадению большинство проектов развивается по принципу “да лан, тут скрипт не сложнее хелло ворлд”, “ну ок, тут это немного добавим, тут это”… а потом сидят программисты с десятками мегабайт монолита и боятся что-то рефакторить, ибо не понятно где что отвалится

а с ооп понятно конечно...

а с ооп понятно конечно...

SOLID, GRASP?

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

типичный Багарт

багарт на голове

ммм аргументы подъехали

этот чат сегодня радует

Говнокод и методика программирования слабо связанные вещи. Возьмите, к примеру, Битрикс какой-нить - ООП в нём, все дела. С другой стороны код фейсбука, которые, учитывая требования HHVM, вероятно, написан с малым исопльзованием ООП. Или стандарт JS едва недавно стал обрастать должным инструментарием для создания ООП кода. Или, вспомним Angular, который писал на паттерн MVC, не смотря что кодится вроде как разрабами от Гугл. Короче. ООП это круто. Но это не значит, что всё остальное плохо.

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

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

поэтому ты 10 строк пхп кода превращаешь в 10 тысяч? )

Я? Нет. Сарказм понятен, но я сомневаюсь, что кода будет сильно больше. В хелооуворлде буквально на 4 строчки - обьявление класса, объявление метода, инстанцирование, вызов метода. И с ростом сложности процент "ненужного" кода будет всё меньше и меньше.

unset($array_1[$key]);

вопрос!

так корректно удалить ключ и значение? и если в цикле то рано или поздно будет пустой массив? верно?

к примеру тот же foreach

Удаляешь верно. Пустой массив тоже получится. А вопрос в чём?

Я? Нет. Сарказм понятен, но я сомневаюсь, что кода будет сильно больше. В хелооуворлде буквально на 4 строчки - обьявление класса, объявление метода, инстанцирование, вызов метода. И с ростом сложности процент "ненужного" кода будет всё меньше и меньше.

ага а потом на ооп начнешь sql велосипедить

спасибо,именно получится на выходу пустой массивв помогли

с орм, ооп фильтрами и прочим маст

ага а потом на ооп начнешь sql велосипедить

Зачем? Уже всё сделано.

так корректно удалить ключ и значение? и если в цикле то рано или поздно будет пустой массив? верно?

да

к примеру тот же foreach

чаще всего разумнее ансетить весь массив

Зачем? Уже всё сделано.

а потом еще накинуть уровней абстракции и DI ?

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

Истина. Чо уж. Но лично у меня большее уважение вызывает, быстрый код в условиях ограниченных ресурсов. До сих с искреннем уважением отношусь тем, кто без ООП писал увлекающие игры на компы в 48К, или те, кто своим кодом заставлял сажать челнок Буран без пилота. Для понимания же кода нужна документация и хорошие манеры при его написании (синтаксические правила). Подчеркну, что это личное мнение, и факт большего уважения не говорит о том, что все остальные не в кассу и сплошь шайтаны.

а потом еще накинуть уровней абстракции и DI ?

а потом чтобы обслуживать это надо брать минимум мидла

обслуживать 10 строк )

А что, где-то есть проекты в 10 строк? Можно контакты, я бы к ним устроился.

А что, где-то есть проекты в 10 строк? Можно контакты, я бы к ним устроился.

зп там рубль в час

Штук сорок, наверное, смог бы обслуживать. По выходным.