Compete in RapidMiner's 3rd Competition: Fantasy Football. Top prize is $750. Deadline December 19.
Download RapidMiner Studio or Server 8.0 Public Beta. Let us know how you like it! Ends November 27.
Watch RapidMiner's "Getting Started" videos on YouTube. Everything you need to do data science - fast and simple!
I am setting up Rapid Miner Servers in Azure.
I will have three instances of Rapid Miner Server.
When I reviewed the installation instructions it said that a Rapid Miner server instance needs an account on SQL Server. My questions is the following:
If I am setting up three instances of Rapid Miner Server in Azure do I need three separate instances of SQL Server, one for each? or can I use a single SQL Server instance and give each Rapid Miner Server it's own schema on the single SQL Server instance.
My guess is that I can do both but that one will be faster or less expensive than the other way.
I'm not the expert when it comes to putting these machines in production but I would think if each server has a unique function, one SQL Server for each is probably the safest bet. Your idea of one SQL server and three different schemas would work too but I'd be careful about that.
On a related note, I would never use the save SQL Server with production data and add a schema for a RM Server on it.
You need to get your terminology right.
A "schema" in standard relational databases is something that you can refer to as a table prefix. E. g. myschema.mytable.
Usually, a "public" schema is used if you don't specify any. That's what RapidMiner Server does, too: there's no way to configure a custom schema.
So the answer to your question is: the connection string has to be different. Usually you would achieve that by creating different "databases" on one "server" or "instance". (Check the documentation on what these things mean with your SQL database vendor.)
So it should be possible to only pay for one "SQL Server instance" if you're able to create multiple logical "databases" in it. Performance-wise, it won't matter much as Server doesn't usually put a lot of strain on the database.
the name is just an example. The database can be called however you like.
If you look at the command line example for MySQL, the introduction is clearly creating a new "database", not just a schema.
If you use "CREATE DATABASE rmserver1" and "CREATE DATABASE rmserver2", you'll get different databases that aren't connected to each other (even if they run in the same SQL Server instance). Then you can configure one RM Server for rmserver1, the other for rmserver2 etc.