Hello. I’m a Korean developer.

Can chatscript be linked to MySQL?

I want Chatbot Q&A to automatically CRUD MySQL data.

I eagerly await your advice.

almost. Code is there in system. I have not yet linked to an external dll for mysql connector, so it does not link yet

Bruce Wilcox - Jan 3, 2018:

almost. Code is there in system. I have not yet linked to an external dll for mysql connector, so it does not link yet

Thank you for your answer.

1. Are there three DB available for MongoDB, Postgres and MySQL?

I want to control the DB from the web with the Chatbot.
2. Which method would you suggest?

Mongo and Postgres are known to work.

What DB to use is pretty much arbitrary. Mongo is a NOSQL type db, Postgres is an sql db but using blobs it can be similar to nosql.  Mysql is an sql db

Bruce Wilcox - Jan 3, 2018:

Mongo and Postgres are known to work.

What DB to use is pretty much arbitrary. Mongo is a NOSQL type db, Postgres is an sql db but using blobs it can be similar to nosql.  Mysql is an sql db

Thanks again for your answer.

If you have any questions during the project, please answer them.

Bruce,

Have you hooked up MySQL yet?

on Windows?

on Linux?

I have tried following the wiki entry for mySQL but it doesn’t seem CS is attempting to connect to my database. I get no errors in the logs or on the console and CS just uses the /USERS directory. I know mongo and postfres have their own executables. Is that true for MySQL also? I see the the mysql .dll file in binaries. Another question is will any of the DBs work on Windows or do they have to be Linux only?

I have been able to get postgres to work under debug mode.  And it works under a high load, with no issues, under linux aws.

I tried to get mysql to work, but I had a challenge getting the correct libraries to install on the linux server.  I am sure it is possible, but I have not spent any time on it.  If you have a choice, I would also agree that you should go for Mongo as your first choice, for CS.  It looks like a more mature implementation for CS.
Hope this helps. Let us know how it goes.

I have found out that MySQL is not quite hooked up in the code yet. When you try to run with it, nothing happens. No errors, and the context is still kept in the USERS directory.

As I understand it there are installations that run 2M users per month on a shared USERS directory. I take that to mean using the File System works just fine. If you look at the database documentation you can see that what really happens is the contents of the user-bot.txt files is just put into and read from a blob in the database. If your File System is local, it should be fast enough. For now we are going to continue using a shared USERS directory with multiple instances of the engine. We are going to be running performance tests soon and I will try to post the results.

You could put up a high end server with multiple CPUS and a lot of memory, and fast disks.
I tried volume testing and a one CPU machine can handle 20k volleys a minute or 3k active users at once, tops.
An 8 CPU machine with lots of memory and fast disk ssd (provisioned IOPS SSD io1) would handle theoretically 150k volleys per minute, or 24k users at once. That is a lot of users and volume.  That is with my CS code. 

The problem with this architecture is that if you have to scale up and down, you end up with a massive server to handle your peak periods.
Because everything is written to a disk, you need to have only one instance of it, and you need to build something that can handle your peaks. And scaling this live single server up and down is difficult. Unless you know of some tricks. 

With a database layer, you can have a load balancer as your front door to your app servers. Have it distribute load to available app servers.
With AWS, you can auto scale your app servers up and down based on load. 
So, if your load goes up, you add a bunch of smaller app servers.
When it goes down, auto kill some app servers.
This lowers your cost.
And all app servers oint to the same database server.
The database servers auto scale also, but this is not as fast. 

With this architecture,  you can scale up and down without impacting the end users experience.
There is a lot more to this, but that is the basic premise. 

If someone is starting out, I recommend putting up a load balancer that points to a single app server that writes data locally.
No database.  If you have very high demand, migrate to the database option.
You would already have people pointing to the list balancer.
You would need to put up new servers that point to the database.
And as a one time task, migrate the local users to your database. 

It is faster to run everything locally, so that is what I recommend as a starter. 
Hope this helps.

If you are going to single server route, you could mount a superfast disk to your server.
Create a 2nd server, also with a superfast disk.
Write a script that does rsync between them both.
Point your user directory to that local mount.
Use a load balancer to point to both app servers. 
I have not tried this, but it would be a good way to upgrade your app server or to have 2 app servers.
Going the dbase route is probably the long term solution if you will need to scale up.