I think Stewart's question was - now that we've gotten rid of a central system database, if we were to store data about tablespaces, where would we keep it?
For my part, I'm not totally sure I agree that it is important the users can manage tablespaces through Drizzle commands. I mean, I hear what you're saying, and if you accept the premise that Tablespaces are good and/or required, then managing them through Drizzle commands is sensible - but I'm always extremely wary of systems that try to re-write all of UNIX. Again. My question is, other than complexity of database config and setup and a possible bootstrapping problem, what is it that tablespaces gain us? We've already got filesystems. We've got LVM. If we're on Solaris or OSX I've got the much-lauded (yet still uselessly licensed) ZFS. OR, if we've wasted^?^?^?^?^? spent money on a big-ass SAN, I've got the storage management features in the SAN. What do I gain by having the database engine manage this itself as well? (I'm both trolling and honestly asking here...) Roy Lyseng wrote: > Stewart, > > this is a good question. Some comments below to start off a discussion... > > Different engines have very different requirements for management of > tablespaces, so I think it is important that tablespaces are managed > entirely by the engine on the micro-level. Yet, on a higher level, it is > important that users can manage tablespaces through Drizzle commands > that generalize the management as much as possible. > > How is this achievable? > > - Create, modify and drop tablespace commands supported by Drizzle. > - Engine-specific parameters to tablespace commands > - Engine-specific namespace of tablespaces simplifies management. > - Tablespace configuration data can be managed by the engine or by the > server, interfaces for both can be provided. > - In the simplest case, the server stores all config data (XML, blob?) > and provides them to the engine when the server initiates the engine. > > In the case of a distributed engine, it is much easier to keep > tablespace information consistent by managing config data in the engine, > in particular when multiple servers attach to the same engine. > > BTW, HADB (a distributed server/engine) does not have tablespaces (or > rather it has a single unnamed tablespace). However, each server node is > given a list of file names on startup, and the concatenated storage > space provided by these files is used as storage space for that node. > Information about schemas and tables and mapping to which nodes they are > stored in is entirely through system-managed tables (the data dictionary). > > Thanks, > Roy > > Stewart Smith wrote: >> On Mon, Oct 20, 2008 at 10:06:59AM +0200, Roy Lyseng wrote: >>> IMHO, forcing the database(schema)/directory relationship is the >>> bigger problem. With tablespaces there would be no need for symlinks. >> >> You also have to think about where this information is being stored. How >> will drizzle know where to look for tablespaces? > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-discuss > Post to : [email protected] > Unsubscribe : https://launchpad.net/~drizzle-discuss > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
