скоростные базы и почемушки
ну вот взять идею со скоростной базой, поддерживающей только часть sql. а чо еще? у меня вот возникают вопросы на предмет хранилищ: вон, mysql поддерживает (к примеру) myisam и innodb. а в чем разница? мне простихосспади транзакционность и другое расширение файлика ни о чем не говорит. ну, говорит, канеш, но немного, мягко говоря.
причем, несмотря на то, что эту фиговину можно ставить потаблично, обычно ставят на базу и везде в табличках копируют. странноватенько, не? и явно фиговенько, раз так.
а ведь судя по всему нагрузка и использование баз и таблиц _могут_ значительно отличаться и именно там можно ожидать конкретного, на порядок прироста производительности. если подумать и подойти качественно.
к примеру, обычные таблички редко пишутся и часто читаются. обычно - с джойнами или аналогом. но есть таблички, к примеру, прайс-листы, где может обновляться куча записей разом. и регулярно. или частое обновление отдельного поля или... это все юзкейсы где чисто еще на уровне "вместо иннодб-пурги придумать получшее" можно зафигачить чо интересное. и таких не сказать чтобы много, так, если честно. я не видел больше нескольких типичных вариантов ваще.
причем, шоп было переносимо - заранее застандартизировать это на usual-writes-insertdeletes-updates какой. или аналог. или взять чисто из практики чо там бывает. к примеру timebased (вот и все шоле? других-то и не припомню, разве что совсем колоночные в аналитике какой еще). и понятно, что если это логи timebased то никаких fulltext полей, которые там нафик не сдались и поэтому хоть колоночно там храни. а если обновляется часто и помногу, то, ну возьми жесткого диска скока надо, x2-x3, ставь тип и ускоряй. чисто по типу базы на уровне хранилища.
идея поняна?
а то - транзакционность... то ли myisam ущербен, то ли innodb тормозной... сидишь и думаешь над названием, а не применением. просто даже simple vs sql-extend назвали бы, уже было бы понянее (тм).
еще вот, взять innodb, в котором select count(*) не кешируется а считается. возникает очевидное "почему", которое относится даже не к технике уже, а к sql наверно. почему я не могу где-то сказать "посчитай", а где-то "покешируй"? не, оно. все. понятно. но смотрите, если исторически кешей в базах не было и тут внезапно (тм) они появились, то может стоило бы придумать средства управлять ими не только сбоку, ковыряясь в настройках, а еще и сверху, через sql?
я вот не понимаю чо мне вещает в exlpain mysql на select * from table где табличка-то небольшая совсем. я бы ее cache select * from и наклал бы даже на наружний мемкеш. если бы. если бы sql еще не просасывал чисто на (видимо? я хз) парсинге запроса и сцуко ну хоть распарс и план бы кешировал чисто строки. запроса. ага. или еще может где чо надо натурально пнуть тяжелым шоп ну на полной, прощее не бывает, хрени не возникало прососов и было бы пусть не похоже на мемкеш, но хотя бы сравнимо.
а то очевидный вопрос "чо простой запрос в базу тупит как последняя скотина относительно кеша на сотне интов" - он же ну, постоянно встречается. мне только, видать. наверное.
потому, что пока будем считать на страничках вот эти простенькие запросы select from where primary_id=1, на которые ни планы не нужны ни парсинги, ничего, кешируй строку запроса, парс и план и фигарь, но где все это идет в полный рост, ни о каких других вещах - не думается. поинтереснее или там еще поскоростнее.
причем, несмотря на то, что эту фиговину можно ставить потаблично, обычно ставят на базу и везде в табличках копируют. странноватенько, не? и явно фиговенько, раз так.
а ведь судя по всему нагрузка и использование баз и таблиц _могут_ значительно отличаться и именно там можно ожидать конкретного, на порядок прироста производительности. если подумать и подойти качественно.
к примеру, обычные таблички редко пишутся и часто читаются. обычно - с джойнами или аналогом. но есть таблички, к примеру, прайс-листы, где может обновляться куча записей разом. и регулярно. или частое обновление отдельного поля или... это все юзкейсы где чисто еще на уровне "вместо иннодб-пурги придумать получшее" можно зафигачить чо интересное. и таких не сказать чтобы много, так, если честно. я не видел больше нескольких типичных вариантов ваще.
причем, шоп было переносимо - заранее застандартизировать это на usual-writes-insertdeletes-updates какой. или аналог. или взять чисто из практики чо там бывает. к примеру timebased (вот и все шоле? других-то и не припомню, разве что совсем колоночные в аналитике какой еще). и понятно, что если это логи timebased то никаких fulltext полей, которые там нафик не сдались и поэтому хоть колоночно там храни. а если обновляется часто и помногу, то, ну возьми жесткого диска скока надо, x2-x3, ставь тип и ускоряй. чисто по типу базы на уровне хранилища.
идея поняна?
а то - транзакционность... то ли myisam ущербен, то ли innodb тормозной... сидишь и думаешь над названием, а не применением. просто даже simple vs sql-extend назвали бы, уже было бы понянее (тм).
еще вот, взять innodb, в котором select count(*) не кешируется а считается. возникает очевидное "почему", которое относится даже не к технике уже, а к sql наверно. почему я не могу где-то сказать "посчитай", а где-то "покешируй"? не, оно. все. понятно. но смотрите, если исторически кешей в базах не было и тут внезапно (тм) они появились, то может стоило бы придумать средства управлять ими не только сбоку, ковыряясь в настройках, а еще и сверху, через sql?
я вот не понимаю чо мне вещает в exlpain mysql на select * from table где табличка-то небольшая совсем. я бы ее cache select * from и наклал бы даже на наружний мемкеш. если бы. если бы sql еще не просасывал чисто на (видимо? я хз) парсинге запроса и сцуко ну хоть распарс и план бы кешировал чисто строки. запроса. ага. или еще может где чо надо натурально пнуть тяжелым шоп ну на полной, прощее не бывает, хрени не возникало прососов и было бы пусть не похоже на мемкеш, но хотя бы сравнимо.
а то очевидный вопрос "чо простой запрос в базу тупит как последняя скотина относительно кеша на сотне интов" - он же ну, постоянно встречается. мне только, видать. наверное.
потому, что пока будем считать на страничках вот эти простенькие запросы select from where primary_id=1, на которые ни планы не нужны ни парсинги, ничего, кешируй строку запроса, парс и план и фигарь, но где все это идет в полный рост, ни о каких других вещах - не думается. поинтереснее или там еще поскоростнее.