Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] A VERY IMPORTANT MESSAGE

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Richard Morris <webmaster@pfaf.org>
  • To: Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] A VERY IMPORTANT MESSAGE
  • Date: Tue, 15 Feb 2005 12:05:09 +0000

Sean Maley wrote:
Thank you Stephanie.

Is there anything specific you have found to be most
useful? It looks like there is some inertia being
experienced right now, which I hope I haven't caused
by introducing new ideas. Heide appears to be a
source of scope creep too. Going beyond plants
specifically. How can you have a system about guilds
with only plants?

Guilds were definatly part of the original proposal.

Along these lines, user scenarios are very important. The usage patterns will drive the interface design,
which in turn drives the design of the back end
package. That leads to why I am so interested in some
of the PIW listserv discussion. The problems will
come as the data set grows. Looking through the eden
package, I'm seeing lots of searching through strings,
known as in-string searches. Done against every table
in a default search, there will be enough trouble
distributing such a load. When you add concurrent
modification of this data, I'm not sure we have that
sort of hardware/software to handle it.

MySQL isn't known for it's transaction control.

I don't think this will really be much of a problem at the outset.
In the plants for a future website/database we have only had one or two submisions a day. At that sort of load MySQL is fine (BTW I'm still reading and writing from text files on pfaf site).
At this point in the project, I would not want to go through the whole process of using a different DB managment system.
Hopefully with a well designed middle layer it should be posible to switch DB.

Where
I thought searches would be the extent of database
work and minimal modifications would ever be
performed, MySQL was the tool. However, this won't be
possible attempting to accommodate a general search
(OLAP) user base concurrently with a data entry (OLTP)
user base.

Perhaps a data entry delay would be considered in user
scenarios. This gives a chance to shovel the data
into the database without search engine disturbance. There could also be a data model addition to index
words found in the database, as an alternative to
in-string searches (edible LIKE '%tasty%'). This
takes up lots of disk, but prevents us from going into
our main set of data via the in-string, thus
increasing concurrency and allowing transactional
control at the DB level. I believe google does
something like this.

MySQL also doesn't give much control over disk usage
either. Would it make sense to keep it in the back of
our minds that we have no set tool for storing the
data? At least not until we settle what the user
community looks like and run some numbers against our
hardware. How many searches are happening now?

PFAF get a few thousand a day.

How
much disk/CPU/network does this generate?

Virtually no CPU, 30MB disk. I think it takes 4sec to do a free text search over whole DB
What can we
expect in terms of usage when we go live? Who else
operates on our host? Am I crazy to bother with
performance questions?

Yep.

You do bring up some important concerns, which may be of importance later in the project. Now I'd prefer to stick to what we've got, focus more on schema issues.

Rich





Archive powered by MHonArc 2.6.24.

Top of Page