Re: [MonetDB-users] mclient - copy into problem

Hello, I think Mark is correct, what makes this software great it's the performance. If we can control server/client interaction from the application/os level then that's perfectly fine. The speed of MonetDB is unbelievable, it's very simple to use, excellent support. I've dealt with lot's of different concepts using b-trees, hash, bitmaps and nothing is as easy and fast as MonetDB, great design. Thanks for your help. Dariusz. Mark V wrote:

On Sat, Jan 31, 2009 at 2:59 PM, Ross Bates wrote:

...

I think what Dariusz is hitting on is the gray area between MonetDB as a storage engine to wrap an application around and MonetDB as a pure database server dedicated to user queries. His comment about MonetDB not being "production ready" falls into the latter category and didn't appear to be intentionally disparaging.

The original email was about how to stop an export process. Here's another related example, if you open things up to users and someone kicks off a query with a cartesian join there is no way to connect to the mserver5 process and kill that individual query without interrupting other queries. Another thing Dariusz inquired about in an earlier email was mserver5 logging. These are all traditional DBA items which are not available in MonetDB. It's really more a perception issue, if you call something a database people are going to have a natural tendency to compare to the other databases they've worked with.

Sure, you can find this a little in the MySQL/Oracle/MSSQL forums - '...but I can do this in Access.' And then you realize they think 'the database' is one and the same thing as 'the GUI query builder'. There is also the perennial, and more difficult, issue of use cases. Some DB servers are optimized and targeted at well defined/behaved queries, other use cases have to allow 'what-ever-you-can-throw-at-it' on a shared server.

One of the nice things about MonetDB is the performance. Personally I favour keeping that perfromance the expense of bells and whistles. and at the cost of some convenience.

It may be useful to collect some tips on 'traps-for-young-players' about what's different about MonetDB cf <whatever> and how to handle that. E.g. The 'anything-goes' use case might involve suggesting running a 'small-test-first' server which users have to pass through without error to get their script to run on the shared mega-production server, etc., etc.

Mark

...

Note: this isn't a commentary on what should or shouldn't be included in MonetDB. MonetDB is open source and the beauty is that people can individually or collectively take things wherever they want. Perhaps you could argue that the collective can work......... awww crap, let's just call it a night. ;)

-Ross

On Fri, Jan 30, 2009 at 6:42 PM, Mark V wrote:

...

On Sat, Jan 31, 2009 at 11:22 AM, dariuszs wrote:

...

Hi, I did not say It's anybodys' fault, I'm simply evaluating the software, I think the software is amazing. All I was asking was - what would I do if I was going to use it in production and I had to deal with situation like this, that's all. Thanks for hour help. Dariusz.

Apologies then. I took your question, "So this database was never intended for production use?", to mean that you'd discovered something about MonetDB which meant it is not suitable for production use, and you wanted to know if that was correct. Whereas, to me, it sounded like your app. was still in the development stage.

For what it is worth.... I think several MonetDB servers can be run on the same machine using different port numbers. This might allow you to periodically setup a 'temporary' server for long-running/fragile 'stuff'. If things go pear-shaped you can kill it off and leave your production server MonetDB running. If you are in a production environment with very stringent availability constraints, and if your app could conceivably do really wild things, you might like to consider running the temp MonetDB servers on a physically separate machines. Depends what trade-offs you can make.

Maybe someone else can make an authoritative comment on any potential pitfalls in either of these architectures.

Mark

...

Mark V wrote:

...

On Sat, Jan 31, 2009 at 6:44 AM, dariuszs wrote:

...

Hi, So this database was never intended for production use? Dariusz.

You've designed your application to do/allow fragile/volatile/experimental things on a production server, a server which hundreds of people depend on - and its MonetDB's fault?

...

Martin Kersten wrote:

> dariuszs wrote: > > >> Hi, >> Well then how do you stop that process? Terminate server? And if >> that's a production machine? Log off hundreds of people? >> >> > The server does not see when a client ceases until it requests the > next statement. The protocol does not include an out of bound message > to warn > the server. > Even if it could, the bulk-processing approach leads to at best > stopping > between two MAL instructions. Such an instruction can take a lot of > time. > > The developments aimed at distribution and automatic horizontal. > partitioning are the handles to better control 'early escape' > > >> Martin Kersten wrote: >> >> >>> dariuszs wrote: >>> >>> >>> >>>> Hi, >>>> Please verify this - when you output a file from the table with >>>> 'copy... into...' and terminate that client - the output file is >>>> still being created even though the client was terminated. Thanks. >>>> Dariusz. >>>> >>>> >>>> >>> Of course. mclient and server are two independent processes. >>> And MonetDB does not let you abort a query easily. >>> So the back-end happily continous to finish the query. >>> >>> >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> This SF.net email is sponsored by: >>>> SourcForge Community >>>> SourceForge wants to tell your story. >>>> http://p.sf.net/sfu/sf-spreadtheword >>>> _______________________________________________ >>>> MonetDB-users mailing list >>>> MonetDB-users@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/monetdb-users >>>> >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> >>> This SF.net email is sponsored by: >>> SourcForge Community >>> SourceForge wants to tell your story. >>> http://p.sf.net/sfu/sf-spreadtheword >>> _______________________________________________ >>> MonetDB-users mailing list >>> MonetDB-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/monetdb-users >>> >>> >>> >>> >>> >>> >> > >

------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users