I have a RoR app that is installed multiple times in the same machine. The app is the same, it's just installed with different names (i.e: app1, app2, ...).
The app uses ThinkingSphinx for searching. It has one index for the model Element. Each installation of the app will have it's own database with its own Elements.
So my question is:
Should I have multiple Sphinx instances running by changing the port, one per app? (I tried this option with 2 installations and it works well, but I think there are some issues regarding server load)
Should I have only one Sphinx instance? In that case, where should I configure Sphinx? How can I configure it to access different databases? How can I tell it to differentiate between instances from different apps?
Should I go with another solution?
Thank you in advance
Separate Sphinx instances (running on different ports) is definitely the way to go.
Sphinx requires every document to have a unique id, even between different index files, so managing that with a standard Thinking Sphinx-generated configuration is painful with multiple applications - you'd need to manage the single configuration file yourself, really, plus adapt Thinking Sphinx to only search across the relevant data set for each app. It could be interesting on some level, but my gut feel is that it's really not worth the effort or time. Use different ports, different daemons, much easier.
Related
I'm in the process of designing a web-service hosted with Google App Engine comprised of three parts, a client website (or more), a simple CMS I designed to edit and view the content of that website, and lastly a server component to communicate between these two services and the database. I am new to docker and currently doing research to figure out how exactly to set up my containers along with the structure of my project.
I would like each of these to be a separate service, and therefor put them in different containers. From my research it seems perfectly possible to put them in separate containers and still have them communicate, but is this the optimal solution? Also given that in the future I might want to scale up so that my backed can supply multiple different frontends all managed from the same CMS.
tldr:
How should I best structure my web-service with docker, as well as assuming my back-end supplies more than one front end managed from a CMS.
Any suggestion for tools, or design patterns that make my life easier are welcome!
Personally, I don't like to think of designing whatever in terms of containers. Containers should be good for deployment process, for their main goal.
If you keep your logic in separate components/services you'll be able to combine them within containers in many different ways.
Once you have criteria what suits your product requirements (performance, price, security etc) you'll configure your docker images in the way you prefer.
So my advise is focus on design of your application first. Start from the number of solutions you have, provide a dockerfile for each one and then see what you will have to change.
I have an idea for a multi-tenant app, and I'm trying to decide if I should use one large database or use separate databases for each tenant.
I don't even know if the latter is possible in Rails, or with rails on Heroku.
I also don't know if this is a good idea, or cost prohibitive.
But I guess to start I just want to know if it's possible.
There are many approaches to multi-tenancy, each with its own pros and cons. Postgres has this nice feature called schemas, which means you can have one database but multiple namespaces inside. This can be a convenient solution for Rails, as Rails was designed for connecting with only one database. It is easy to integrate with apartment gem. It takes care of migrations and tenant switching based on specified rules, usually subdomain. But this solution has downsides. While Postgres does not have any limitation on number of schemas, when you have a lot, migrations will take forever. And there are problems with backups. Heroku recommends using less than 50 schemas.
If you want to have multiple physical databases then it is a little bit tricky with Rails. There are some gems that allow connecting to multiple databases. Recently I heard about octoshark gem, but I haven't use it.
In summary, Postgres schemas are nice if you want to have good isolation without too much work. It will be also cost efficient on Heroku, as you will use only one database. But it won't scale for a lot of tenants. Multiple databases provide the best isolation, but support for this solution in Rails is not that great I think. And it will be costly as you you will need to provision separate database for each tenant. And the last resort is to just use one database and scope all your tenant data with tenant_id. In this solution you need to guarantee isolation which requires additional work and it is easy to miss some parts of the application.
I am starting work on a new project soon and was wondering whether to create multiple apps (pretty much copies of each other) or one single app (or utilize single sign on of some sort). Each 'app' will have its own domain.
The apps are pretty simple, people can sign up to the site and create a profile for their cat or dog. However, as some people have a cat and a dog, it would be nice to not have them sign up twice. Also, I think many users will want to extend to other pets too, such as rabbits, rats, ferrets, etc
It will be a Rails app, and so I wondered what my options are.
A single app would be easiest to maintain
Multiple apps could mean it is easier to 'split' the network i.e sell some of it (tho I doubt I'd do that)
But which would be most efficient? Would there be any problems with caching? Which makes most sense?
If you have any links or info on how to go about your preferred method, that would be appreciated too! But at this stage, I am mainly asking about which is the most logical way to go about it.
Less is always more, especially early on in a project.
I've learned to never split code bases until it's absolutely apparent that it must be done.
Making 2 apps means twice as much work in so many ways. Two bundle exec rails server to run, two bundle exec rspec to run, cd .., cd web_app1, cd web_app2 over and over.
You also have to deploy two apps.
So, make one app. Split it up later, if and when you need to.
If they are on the same subdomain, you can share cookies, and easily achieve SSO.
And there is no reason you can't use something like nginx to put them behind their entirely separate domains, as a deployment consideration.
If you were planning to have multiple domains with a separate application on each domain, you could have a "central" domain (or server) that can hold all shared resources (images, css, javascript, data etc) and provides the ability to load-balance and increase performance. It can be a lot of work connecting everything and keeping it all running so it depends on your situation.
I am reasonably new to Ruby on Rails so I am not sure how to implement this. My understanding is that rails is not designed with multiple databases in mind, although I could use establish_connection etc to make it work.
My main problem is:
I have an SaaS/application that will serve several businesses. Each
business will have several database tables such as: users, comments,
messages, transfers, navigation history, logs etc. It seems I have 3
options:
1: Store everybody's data in one database with every object belonging_to a business or just tagging something like a businessID/name. Use this tag to fetch the appropriate data and worry about scaling/performance later as my app grows. (Would I have to worry about this pretty early on?)
2: One database per Business. No need to store associations, and db queries perform consistently throughout the application's life (possibly bad assumption here).
3: Have separate instances of my app each running some number of businesses (not sure this is any good).
What I have seen used in other frameworks/businesses is just (2) multiple dbs.
I am also really interested is what is the best practice in rails as well. I know several applications have this same problem and hearing how this has been solved will help.
Any help is much appreciated. Thank you so much.
Env.
Ruby 1.9.2
Rails 3.1
Production:Heroku or EY (still deciding, now running on heroku)
According to this page, You'd need to apply some metaprogramming for multiple databases.
Why not make your deployment script to deploy to different directories with different database settings? One branch per business? Might require some more maintenance, but allows for per-business code if you need it.
I'm developing an app (basically an intranet) which has a few small sets of users, each a company using the app internally.
Up to now, each set of users has its own deployment with a separate domain name and database, but all living on the same server. This means that each time I have to push an upgrade I need to deploy once per client. Also, each new client means adding a new deploy target, for which I'm currently using Capistrano's multistage plugin, but it's getting a bit ridiculous.
This is a less than ideal setup, so after some thought I came up with the idea of modifying the app so that it handles multiple domains, each mapped to a different database, but on a single deployment. I created a small proof-of-concept app which basically has a before_filter in ApplicationController acting as a multiplexer for domains/databases, connecting ActiveRecord to each domain's database on each request. This worked really well, but I haven't applied this to the big app yet and I can think of at least one problem down the road: running migrations across all databases. I'm pretty sure I can work around that one though, maybe I'll tweak the rake task a little, but I'm worried that might not be the last of problems with it.
Has anyone ever tried this, or can think of any major reasons why this would be a bad idea? I would like to listen to some opinions.
Thanks!
This is usually called multi-tenancy. Here is a presentation or video about doing it in rails. Couldn't tell if it was any good, it was blocked here at work.
And no, there is nothing wrong with it as an idea. I'm not sure about your particular implementation, but I have worked on apps that were multi-tenant in the past and can't say we ever had much difficulty except when trouble clients wanted to stay on a legacy version of the product and we wanted to move forward.
I have a similar app and still the same problem as you, and after many tries, i ended up (before a desirable core solution came) with one env file per domain and kind a filter like yours.
I've been running in production for almost 1 year, and the only problem i detected is that rails expected the main db (even you won't use it) to have the same migration level as the others. (this problem arise under certain conditions)
If you need futher details, just let me know.
I hope this helps.