0

Possible Duplicate:
What are some good, fast persistant storage options for key->value data?

I wanna design a php-mysql cms and wanna have a registry system. I have many variables that are global for all users and they may change anytime. I try to make a table in mysql and a row in text that contain all my registry values in serialized mode. but it can very slow in big sites. and if I have one row for each variable it can hang-up when registry get heavy. my registry can have up to 1000 variables or maybe more. what is the best method to have a registry system that be fast and optimized for big websites?

Community
  • 1
  • 1
IVIR3zaM
  • 567
  • 9
  • 23
  • Reduce the amount of data. And store values normalized so you can request specific ones more easily. – hakre Nov 23 '11 at 08:43
  • If you only have key-value-pairs, a singleton-pattern in combination with lazy initialization should probably be the way to go. Otherwise, here are some alternatives discussed: http://stackoverflow.com/questions/1812472/in-a-php-project-what-are-good-ways-to-store-access-and-organize-helper-object. Another way could be an `*.ini`-file (http://php.net/manual/de/function.parse-ini-file.php) – Quasdunk Nov 23 '11 at 08:47
  • the data can be from plugins and each plugin can have unlimited registry values. the big problem is some variables update in each page render, and its stupid job that I update a big text row for only one registry value. what is your opinion? – IVIR3zaM Nov 23 '11 at 08:48
  • 1
    I'd strongly advise against using a Registry, it will only make your life needlessly difficult in the long run, and they're really just global variables with a fancy name. (In case you weren't aware, global variables are Bad. There's plenty of explanation as to why if you google for it) – GordonM Nov 23 '11 at 08:51
  • @IVIR3zaM Are the variables just updated for the view or o they need to be stored permanently on change? What do you mean with 'a big text row'? A registry contains all variables in an array, if you want to change a value, you just say something like `$data['key'] = $value;`. So what exactly is the question? Do you want to know the pros and cons of the alternatives (see my comment above) or don't you know how to organize the data as a whole? – Quasdunk Nov 23 '11 at 08:57

1 Answers1

2

the data can be from plugins and each plugin can have unlimited registry values. the big problem is some variables update in each page render, and its stupid job that I update a big text row for only one registry value. what is your opinion?

You need to update a chunk of data while you only need to update a subset of that chunk. That works contrary to what databases do best. So you're fighting your storage layer. Even if you switch to MySQL with Memcached you still update the whole chunk instead of the particular value.

This is always overhead. Regardless which type of database you use.

If you offer an interface to the "registry" (not the pattern, probably you better call it option store) for plugins, the interface should be able to store values normalized and not serialized. If you put serialized data into your persistence layer, you have the overhead to parse it again when obtaining / setting data.

If you have an array with 500 values and you only need to change a single entry in there, you still have the roundtrip for 500 values and you need to update the whole row. You have not shared much about your interface so it's not easy to give suggestions how this can be done more lightweight.

hakre
  • 193,403
  • 52
  • 435
  • 836
  • thanks. my interface allow plugin developers to store/update/delete options and values. that this values maybe use for options that only update in plugin administration area, that is no problem. but sometimes they need store something like number of visited a page that update in every page render. this can crash my registry system when I do it with a text row or an ini file. and my cms can install in many type of servers (absolutely shared host), so they cann't install any addition application on their host server – IVIR3zaM Nov 23 '11 at 10:15
  • So you want to explicitly state that users are bound to MySQL as storage? – hakre Nov 23 '11 at 10:36
  • yes, or something like that. I saw an cms called e107, in this cms they do it with a text row in MySQL, that is so stupid. and only good for store options. if you update a variable in registry the hole text row will updated. and when you install many plugins it crashed. I saw in some e107 websites when you open a page a text row that have 64KB get updated, and the text row locked until update finished. when website had 100 users online, it really crashed. is another way for do that? – IVIR3zaM Dec 12 '11 at 10:37
  • 1
    Sounds like that the database has table locking instead of row locking. Switching to a database storage that supports row locking could lighten the burden easily. For MySQL the InnoDB tables support row locking. Next to that make the connection between the PHP script and the database faster so that 64kb are transfered faster via the wire. Talk with your sysadmin which options you have. – hakre Dec 12 '11 at 20:53
  • thanks dear. I solve this with an InnoDB table that have 3 columns. ID, Key, Value. and now with one SELECT query I can get all the data an store my data in an array. but I need a little help for type of value. my values can be integer, text, boolean and always array. for store the data of one registery value the only ways I found are 1- serialize the value 2- dump value too text with var_export(). the No 1 is so secure and I heard serialize have heavy process. the No 2 must run with eval() that have low security. what is your opinion? – IVIR3zaM Feb 01 '12 at 09:47
  • 1
    Create a value object that represents any of those you need. Make it serializable. Store the serialized form of that object into a blob field that has enough size. That done, you stay in control and it's encapsulated. You can then later on change the way how that value object is serialized in case you might need it. This is compatible with `serialize` but the pro version. `var_export` + `eval` I would not consider much, won't say that is a good alternative at all. – hakre Feb 01 '12 at 15:28