а ты про кеш не вспомнишь?

Кешить можно всё что угодно, в тч запросы к массивам и тут mysql со всеми своими механизмами будет далеко сзади)

Юрий, здесь мало таких... интересующихся, тут больше думающих... надеюсь

Поэтому вообще непонятно что с чем ты сравниваешь.

Что такое запрос к массиву?

Ат, юморист) Своим тестом я не пытаюсь доказать, что mysql нужно всюду заменять массивами. Просто в ряде высоконагруженных задач массивы (посредством некоторой несложной библиотеки) становятся вариантом выбора. Вероятно, многие интересуются высокими нагрузками, оптимизацией ресурсов - им сравнительные тесты могут быть интересны. Можно оптимизировать mysql аспекты (индексы, запросы), но и массивы с тем же успехом можно оптимизировать. Ещё можно применять редис или какое-либо иное внешнее решение. Но что если вспомнить о ресурсах самого пхп - я вот скорее об этом.

еще вопрос такой. а если записей не 50миллонов а 50триллионов?

Что такое запрос к массиву?

К примеру, классический перебор и сравнение.

А в каком ряде высоконагруженных задач у тебя данные лежат в 100 файлах ПХП ?

Главное не проверять, как быстрее спуститься с 20 этажа - на лифте или по воздуху из окна

А в каком ряде высоконагруженных задач у тебя данные лежат в 100 файлах ПХП ?

у меня лежали :))

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

ноони были закешированы в памяти байткодом

поэтому работалошустро

если не меняющиеся данные, то почему бы нет

еще вопрос такой. а если записей не 50миллонов а 50триллионов?

Если это террабайты данных, то MySQL организуется по схеме горизонтального и вертикального шардинга (на физическом уровне это Ethernet) - и тут всё понятно. Что касается гипотетического решения на файлах/массивах, то я пока не панимэ как организовать серию серверов в кластер к которому могут иметь доступ несколько веб-серверов, на которые направляются запросы пользователей после балансировки. То есть не уверен что на физическом уровне можно так объединить сервера. Если схема решения всё же есть, то я б затестил. Но опять таки, скорость определяется узким местом - интерфейсом объединения серверов.

Если это террабайты данных, то MySQL организуется по схеме горизонтального и вертикального шардинга (на физическом уровне это Ethernet) - и тут всё понятно. Что касается гипотетического решения на файлах/массивах, то я пока не панимэ как организовать серию серверов в кластер к которому могут иметь доступ несколько веб-серверов, на которые направляются запросы пользователей после балансировки. То есть не уверен что на физическом уровне можно так объединить сервера. Если схема решения всё же есть, то я б затестил. Но опять таки, скорость определяется узким местом - интерфейсом объединения серверов.

вертикальный шардинг... очень интересно, коллега. продолжайте

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

вертикальный шардинг... очень интересно, коллега. продолжайте

ну это таблицы по серверам вроде

но никто не называет это вертикальным шардингом :)

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

> по схеме горизонтального и вертикального шардинга то есть диагональный шардинг

А в каком ряде высоконагруженных задач у тебя данные лежат в 100 файлах ПХП ?

Представь, у заказчика говнохостинг и выделить на нём оперативки более 128М - ну это топ а то и меньше. Я не говорю ещё о max_allowed_packet для MySql. В подобных условиях, к примеру, прайс на 50 млн позиций будет адским хайлоадом и деление данных на файлы единственный вариант. Можно решить железом, но с другой стороны, почему бы не задуматься над архитектурой, которая будет масштабируема и эффективна. Хорошая архитектура выдержит как прайс на 50 млн позиций, так и очередную соц сеть на 100ни млн юзеров. И я не говорю что массивы это панацея, но показываю, что они как минимум в ряде случаев могут быть эффективнее sql бд.

а как ты засунешь 50 млн записей в массив если у тебя 128мб оперативки?

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

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

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

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

иди про html-формочки нубам поясняй, как из отправлять, не забывай упомянуть про паттерны и антипаттерны с юнит тестами - реально сразу прям авторитет ??‍♂️

Юра борзый :)

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

хайлоад-мастера

срачик

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

а как ты засунешь 50 млн записей в массив если у тебя 128мб оперативки?

Я его потому и разбил на 100 файлов по 500 000 запмсей в каждом. Это реальные цифры но задача гипотетическая. И да, повторюсь, индексами можно обложить и массивы, что увеличит скорость в неменьшее количество раз. И снова, повторюсь, не настаиваю, скорее как деление опытом. Не утверждаю что опыт илеальный) Нооо я бы предпочёл читать об опыте коллег; расшифровыать новичкам очевидное мне менее интересно.

Я его потому и разбил на 100 файлов по 500 000 запмсей в каждом. Это реальные цифры но задача гипотетическая. И да, повторюсь, индексами можно обложить и массивы, что увеличит скорость в неменьшее количество раз. И снова, повторюсь, не настаиваю, скорее как деление опытом. Не утверждаю что опыт илеальный) Нооо я бы предпочёл читать об опыте коллег; расшифровыать новичкам очевидное мне менее интересно.

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

Представь, у заказчика говнохостинг и выделить на нём оперативки более 128М - ну это топ а то и меньше. Я не говорю ещё о max_allowed_packet для MySql. В подобных условиях, к примеру, прайс на 50 млн позиций будет адским хайлоадом и деление данных на файлы единственный вариант. Можно решить железом, но с другой стороны, почему бы не задуматься над архитектурой, которая будет масштабируема и эффективна. Хорошая архитектура выдержит как прайс на 50 млн позиций, так и очередную соц сеть на 100ни млн юзеров. И я не говорю что массивы это панацея, но показываю, что они как минимум в ряде случаев могут быть эффективнее sql бд.

Напомнило https://www.youtube.com/watch?v=Jr_vcPCGBbk

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

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

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

кстати тв своем тесте наверняка не прогрел ее

до теста

Юра борзый :)

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

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

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

уймись)

массивно ориентированное программирование)

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

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

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

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

уймись)

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

зато через окно быстрее...

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

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

работа с говнолегаси подрывает нервную систему ...

Мы 3 года назад искали по массиву грузили 90 гб в память. и искали там что нужно. Разделяли на массивы по меньше. в реальности оказалось не очень. быстрее и дешевле грузануть чем пилить костыли с разделением

Мы 3 года назад искали по массиву грузили 90 гб в память. и искали там что нужно. Разделяли на массивы по меньше. в реальности оказалось не очень. быстрее и дешевле грузануть чем пилить костыли с разделением

а почему массивы?:)))

мы делили апельсин...

а почему массивы?:)))

ну не массивы . там жсон бы сгенерированный хД мвп такой был.хД

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

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

так я и глупости не несу в этом чатике...

надеюсь...

ньюрелик прикольная штука...

2) Залил эти же пары в таблицу MySQL. Сделал по сути ту же выборку, но только, понятно, через SQL запрос

сделай несколько выборок

ай стоп

ты ВСЕ данные загружаешь?

тогда смысла ясное дело нет...

но никому не нужны сразу все 50кк данных

их селектят по ид

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

ERROR: S client not available

надеюсь...

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

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

ты с Тарасом не знаком?

ты с Тарасом не знаком?

ну наконец-то я что зря видео искал. хД

Да это поди Тарас под другим именем…не бывает 2-х таких людей же)

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

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

ах зачем я перед сном посмотрел в слак... опять что-то упало

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

до хранения данных в файлах я дошел лет так 25 назад... и пошел дальше

до хранения данных в файлах я дошел лет так 25 назад... и пошел дальше

картинки, видосики и пр. бинарники в блобах уже 25 лет?

картинки, видосики и пр. бинарники в блобах уже 25 лет?

софизмы не надо плиз

миленько...

3.1) SQL выборка заняла 53 сек. (на 26% дольше)

Дай угадаю, like %xxx% и без индексов?

я бы хотел поприсутствовать на собеседовании с этим чуваком и соверешенно не важно с какой стороны стола он будет сидеть. Это определенно будет весело :)

я бы хотел поприсутствовать на собеседовании с этим чуваком и соверешенно не важно с какой стороны стола он будет сидеть. Это определенно будет весело :)

пособеседуй любого "пхп сеньора" в питере - услышишь и не такое

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

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

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

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

а по теме поста. Научная работа не обязана иметь под собой прикладное значение. Надо отнестись как некое испытание - "А давайте без оптимизации MySQL сравним и Array в php". До этого исследования никто бы точно не сказал на сколько одно медленнее другого. С практической точки зрения, тоже не понимаю при каких условоиях нужно затащить 50млн записей в память и с ними потом оттуда работать.

А точно правильно на аргументированную точку зрения говорить что глупости это всё до чего ты не дошёл? Звучит как "сперва добейся". А научная работа обязана иметь строгую методологию, которой не предъявили.

Стоило "разместить объяву" о скорости работы массива в сравнении с MySQL в рамках частного теоретического случая и понеслось ))) Я уже, оказывается, предлагаю заменять MySQL массивами во всех задачах и, конечно, делаю это сидя на собеседовании у местных сан-сеев, которые привыкли поднимать своё ЧСВ за счёт ответов на вопросы а-ля "не подскажете, почему PHP не работает" ) Амежтем, мне не более чем интересно изучать возможности интерпретатора в нюансах, к примеру, связанных с потребляемыми ресурсами, сравнивать эти возможности. И, сколько я не видел подобных тестов, подобными вопросами занимаются как раз люди с опытом. Хотя, наверное, опытом не таким большим, как у здешней петросянии.

Стоило "разместить объяву" о скорости работы массива в сравнении с MySQL в рамках частного теоретического случая и понеслось ))) Я уже, оказывается, предлагаю заменять MySQL массивами во всех задачах и, конечно, делаю это сидя на собеседовании у местных сан-сеев, которые привыкли поднимать своё ЧСВ за счёт ответов на вопросы а-ля "не подскажете, почему PHP не работает" ) Амежтем, мне не более чем интересно изучать возможности интерпретатора в нюансах, к примеру, связанных с потребляемыми ресурсами, сравнивать эти возможности. И, сколько я не видел подобных тестов, подобными вопросами занимаются как раз люди с опытом. Хотя, наверное, опытом не таким большим, как у здешней петросянии.

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

Дай угадаю, like %xxx% и без индексов?

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

а MySQL vs SplFixedArray тесты проводились? стоит перехеодить на второе?

а MySQL vs SplFixedArray тесты проводились? стоит перехеодить на второе?

SplFixedArray быстрее стандартного массива, который уже в рамках частного случая порвал мускуль ))) (интересно, припекёт у кого-то от "порвал мускуль")

а че за случай такой частный?

а по теме поста. Научная работа не обязана иметь под собой прикладное значение. Надо отнестись как некое испытание - "А давайте без оптимизации MySQL сравним и Array в php". До этого исследования никто бы точно не сказал на сколько одно медленнее другого. С практической точки зрения, тоже не понимаю при каких условоиях нужно затащить 50млн записей в память и с ними потом оттуда работать.

любая научная работа должна содержать НОВИЗНУ!

а че за случай такой частный?

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

А точно правильно на аргументированную точку зрения говорить что глупости это всё до чего ты не дошёл? Звучит как "сперва добейся". А научная работа обязана иметь строгую методологию, которой не предъявили.

Не могу дать оценку как нужно себя вести. По части исследования полностью согласен. Методология должна быть.

любая научная работа должна содержать НОВИЗНУ!

Бенчмарк "не оптимизированный мускул vs голыемассивы". Я такого еще не видел)))

Ребят, да какое исследование и ресёрч? )) Ну мне самому смешно ) Не более чем один из тестов. Ну провалилась на нём мускуль - ну тем и интересен показался ))

Бенчмарк "не оптимизированный мускул vs голыемассивы". Я такого еще не видел)))

гуглом чтоль стоит научится пользоваться ©