I've found similar posts on this forum, but migrate it to another one if needed.
We want to migrate to PostgreSQL from Oracle, but we have 6000 users simultaneously connected to a 4 To GIS database(divided in 1 To instances) and many other instances for WebServices.
Before looking at other problems, we heard that 500 max connected users is the max limit supported before performances decrease, decrease augmented when size of database become huge.
Have you got any (or do you know links to) successful experience on such a migration?Do we have to wait for PostgreSQL better performances to migrate?
EDIT
Found another example.
Please, read this article on the subject by Kevin Grittner, it will explain a lot on why many connections are problematic and what were the decisions by the PostgreSQL Core Team to approach this issue.
For the list of success stories, refer to the EnterpriseDB site, this is a company offering support for the standard PostgreSQL distribution as well as support and licensing for the advanced products built on top of standard distribution. For the enterprise database usage Postgres Plus Advanced Server might be a good choice.
Related
I read some posts here, but a real answer I didnt find.
Normally I work and worked with normal SQL Databaeses (MS SQL, MySQL), when I developed applications (ERP, CRM, PPS, Web Shops etc.). A real contact/experience with document-oriented databases in real business was not possible.
Only in a private sector (hobby, experimental projects) I tested MongoDB and CouchDB. The experience was good, but not enough to say "Yes, let it use for business!", because I could not test it in a real environment.
But now, there is a chance to program from zero, which could be a big start for a business.
So my question:
Can I use Couchebase for a big business application, where thousands users would use it. Is it so fast and with good performance to handling thousnds of queries, requests/reposts etc.?
How looks like with backup and restore?
Where is the limit of couchbase?
Thank you for the anwser.
In short, yes.
Your questions are too broad to fully address here. Couchbase has many real-world installations with clients doing production work at large scale. You can see several references with write ups of their uses on the Couchbase site. (Note this is not a complete list of customers, only ones that have agreed to have their use highlighted.) You will definitely recognize some names.
Does PreparedStatement.setFetchDirection(ResultSet.FETCH_FORWARD) make a difference for an Oracle DB?
I'm on project to upgrade the database and application server for the power facilities and line maintenance system of a large electrical utility company. We are testing the new set up now (Oracle 12c and JBoss 7).
Sometimes the queries to the db are taking minutes to get an answer. I've suggested doing PreparedStatement.setFetchSize(int rows), where rows being the number of rows of information the user wants to see on his screen. Many posters here in Stackoverflow and elsewhere have said setFetchSize() is important to getting the network connection optimized.
But I noticed the PreparedStatement also has setFetchDirection(). There's FETCH_FORWARD, FETCH_REVERSE and FETCH_UNKNOWN. I've seen this mentioned many times, but I've not seen anyone saying how much of a benefit it is.
If it helps to understand the situation - the power company services 30 million customers, with decades of records (from nuclear power plants down to utility poles). The users of the service will be maintenance crews, office staff, both from with the company and from subcontractors. So, the computer skills and patience of the users may not tolerate a 3 minute wait to find the locations of the transformers they need to repair.
Oracle says
"The JDBC 2.0 standard allows the ability to pre-specify the
direction, known as the fetch direction, for use in processing a
result set. This allows the JDBC driver to optimize its processing."
However Oracle also says "the Oracle JDBC drivers support only the forward preset value" ResultSet.FETCH_FORWARD
"The values ResultSet.FETCH_REVERSE and ResultSet.FETCH_UNKNOWN are
not supported."
So, my guess is that if you are using JDBC 2.0 standard drivers, then you can optimize fetch by saying setFetchDirection(ResultSet.FETCH_REVERSE) when wanting to find overdue maintenance work. But if you are using Oracle JDBC drivers you are out of luck.
(Downvote me if I'm wrong - I know that improves your geek creed.)
I am very interested in using monetdb as a datamart, holding some huge data tables for querying and reporting
However, after some searching, I am unable to find any online posts / blogs regarding their use of Monetdb in any kind of production capacity.
Also, there seems to be little or next to no activity online regarding Monetdb.
Is this a bad sign for the future of Monetdb ?
I am very interested in using monetdb as a datamart, holding some huge data tables for >querying and reporting
My boss is also interested in MonetDB and I had the same reaction as you. No one is writing about MonetDB... is no one using MonetDB?
Regardless, I have been running performance tests on datasets of 500,000 to 1,000,000 records comparing MonetDB (column-oriented dbms) vs. MySQL (row-oriented dbms) and MonetDB beats MySQL in all regards- even in bulk inserts... which hypothetically it should not be as good at.
I can't speculate as to what all this means for MonetDB's future, but while it's around you might want to check it out because it performs well.
(I run Windows 7 and am communicating with each database using PHP)
I react a bit late to this post, but I'd like to add my voice to the ones using MonetDB in a production environment. We use it as the back-end of Spinque, a framework for designing complex search solutions. I've been using MonetDB for about 10 years, but only in the past 3 years in a production environment. Clearly, it has pros and cons and bugs like all other products, but it is being developed and improved very actively (I don't understand the low-activity signs that you refer to). If you want a DB that allows you to be ahead of the market standards, it's a good choice. Otherwise, just go for MS SQL ;)
I've been evaluating it lately for a client so I've had some time with it. My impression at this point is that it is just finishing "growing up" from being an academic experimental playground. It clearly has yet to be really discovered, though it does have some rough edges which might hinder certain applications.
As I write, I'm in the process of trying to load over 100 million rows into an instance (at 27mil presently). So far, it performs startlingly well in some areas (aggregates), but is oddly sluggish in others (most joins I've tried so far); that said, I've not yet run the recommended sampling process yet and I'm forcing it to live in just a single service with 32GB RAM.
I've found a few little glitches and one thing that caused a full service crash (obscure and reported), but I'm thinking that for many applications MonetDB could be just the ticket. Columnar storage (rather than NoSQL) seems to be the future IMO.
I'll update this if I find anything particularly interesting.
MonetDB is first and for all a research system, but has progressed far beyond the level of the average research prototype. It is the (only) relational column-store platform in open source that I know of that supports full SQL. I have used it myself at CWI in many research projects that are not core DB research, but do need advanced DB technology.
You can see on the user's mailing list that deployments happen in many different organisations. As Roberto Cornacchia stated in a different answer, it is the backend of all Spinque deployments and we are happy MonetDB users. MonetDB is also used at a variety of non-profit projects like open streetmap and open kvk.
More and more commercial parties deploy MonetDB for analytics. (They do not always like to advertise that their analyses depend on an open source system.) Recently, MonetDB Solutions has started to provide dedicated commercial support for these deployments.
We have been using MonetDB in our business. We analyse very large data sets with many millions of rows. Traditional methods of data warehousing on SQL databases became so slow. The problem we were facing was that the data was only going to get bigger! The only way forward was to go columnar.
The results have been amazing. When you have very few joins it is staggeringly quick. Even with joins on the data sets we are looking at it is still frightening how fast it comes back.
Having seen some of the commercial partnerships I think MonetDB is going to boom over the next few years. I believe some of the major BI suppliers are using Monet under their hood to perform the large data work.
We are interested in installing Mantis but we have some doubts Please clarify as early as possible if you can so that we can go for further process.
1) We have one team at USA (Client’s place) and one is at India. In which server we should install the Mantis. If we are installing at USA will it run slow in India?
2) What about technical Support. You may take technical support with payment. But how much support will be given free (As we have to discuss this with client).
3) As we have seen details in your website, you have given it supports oracle and sql database. But we wanted to know till which lowest version of oracle and sql it supports. Please send us minimum requirement.
4) What is the capacity of the database to store defects? Backup facility is available? If yes please tell us how should we take. Because we have big team and 5-6 applications so it should not give further problems.
5) Database support: Do you provide database support or database while installation? While installing all the prerequisite application will get installed or we need any application separately.
6)How many users can access at a time? Will it work slowly if more users are working at a time?
Thanks
Komal
1) assuming you can get a similar Internet link, place it where you have more users
2) assuming you have a VPN and LDAP running, you aren't likely to need heavy technical support unless you want to customize it, but anyway, Mantis provides support information on it's web
3) do you have a good reason why you don't want to use MySQL? Sure, you seem to have Oracle and MSSQL expertise in-house, but it's not like you would have to develop on MySQL: it's just basic infrastructure, one not very expensive to maintain.
4) It is unlikely you'll run into capacity problems unless your team really is huge. The database will store as many defects as needed. Backup: mysqldump --user username --password > dbdump.sql
5) you generally install the RDBMS and Apache separately and then deploy the Mantis application on top of those, dedicating an empty database to the application
6) slowdown is inevitable with a growing number of users, but that's beside the point: what's important is what kind of hardware you have and how many users. There have been a couple of discussions about Mantis performance (e.g. this one and this one) but they are really quite old and are a bit on the extreme side (100k users).
My boss asked me to do a research on available CMSes on market because cms we are using currently is rather a mess.
For me as a .NET developer it would be great to choose and implement Dynamics CRM because of extensibility and perfect integration with .NET environment and well-known tools.
All marketing sounds great but I'd like to know about common DISADVANTAGES, ISSUES concerning this system.
The most important is how it is performing in a company with about 150 concurrent and very active users. I heard that it's really slow comparing to competitors system.
The Dynamics CRM Product team has published an excellent whitepaper with guidance and benchmarks for 500 concurrent users. You can learn a lot by studying this paper. The link is here:
Microsoft Dynamics CRM 4.0 Suggested Hardware for Deployments of up to 500 Concurrent Users
I can't answer regarding the number of users/activity. I can refer you to the SDK article 'Performance Best Practices'. I'll speak to the side of you that would be writing plugins (to data access messages), custom pages accessing the CRM web services, and writing SSRS reports. A couple of points I can relate to:
Disable Plug-ins. This is an attractive and major integration point into CRM. The fact that they list it as a performance issue is disheartening. We have seen OutOfMemory exceptions stemming from the plugin cache. We got around this issue by deploying to disk rather than database. In the database they reload the assembly and confirm the signature every time a plugin is called. We believe this was eating up the Large Object Heap. Probably not an issue for your normal CRM implementation.
Limit Data Retrieved. Definitely. Avoid lookups/picklists/bits you don't need when you can as these cause an extra join. Not going to be a huge deal on smaller entities. But if you need entities with a large number of attributes it could be. Probably not an issue for normal CRM customization. A good design in other cases should avoid this issue.
I can't really offer any advice on how it compares to its leading competitors. I know the main thing is that its cheaper and very actively developed.
I can say a bit about performance though which might help.
We have about 400 - 600 concurrent users using the system. The system isn't particularly web server intensive. We have two for resliency - it would be a disaster if it went offline, but these servers are never taxed. They have a couple of virtual cores and 4 gig of ram.
Our database is 130GB in size and is hosted on a 24 core database server with 48GB of RAM. It is clustered but because SQL server can't handle two active nodes, only one server is ever active.
The database server really never gets maxed out. However, there is one very important change we needed to make and one that I think MS are advising all users of large CRM installs to do now. By default SQL Server has a locking mode that will block people writing to the database when a row is being read. In our system (and numerous others apparently) that was causing huge issues.
We switched on a different mode (I think its called "snapshot isolation") or something like that. To be fair though even if you did have 200 concurrent users, it won't be any issue until the more central tables like activitypointer and account get pretty large (in the millions)
So - there is no doubt that CRM 2011 can handle that many users as long as you have some suitable hardware and have someone who understands SQL Server
HTH
S