PlanetMysql.ru — информация о СУБД MySQL

We wish all our customers, users and partners a Merry Xmas and a Happy New Year.

The year of 2011 has been a terrific year for us.  But first let us have a look at where we started 10 years ago. The first version of SQLyog was released in the spring of 2002 – what will mark our 10 year anniversary as a company early next year. In the period since then we have seen quite a lot of other MySQL clients come and go. We are happy to see most of our existing customers upgrade regularly, to see our user base increase, and we are happy to do our best to provide the solutions requested by users and to keep pace with MySQL development.

And also 4½ years ago we added MONyog to our portfolio. So there will be another important anniversary to celebrate in 2012 as well. MONyog has also proved to be robust and long-lived.

We are continuing to develop both programs aggressively in interaction with users and partners. And the combination of SQLyog and MONyog under one hood has enabled us to achieve important strategical partnerships across the MySQL ecosystem.

And don’t forget that Webyog is not only tools for MySQL. Also Visifire has now become a very respected charting solution for Silverlight, WPF and Windows Phone. Several benchmarks and reviews list Visifire as the most efficient and most competitive solution. Our Issueburner application provides an integrated issue-tracking and helpdesk solution in a single and very competitive package. And add to this Cloudmagic that in a second finds various information from Cloud-based services and presents it all in a unified interface.

The diversity of the different solutions that Webyog now offer is important not only for us as a company but also for users, because it ensures robustness of our company and guarantees continued support for all customers also if one of the ecosystems where we operate should face a slowdown or setback for a period. We have the robustness to continue developing what we want and what we have planned in a turbulent world.

We have more in our bag that we will share with you soon, Stay tuned!

PlanetMySQL Voting: Vote UP / Vote DOWN

There is a huge amount of buzz around NOSQL, and we at ScaleBase are happy to see companies making the move to NOSQL. Despite what some people might think, we consider it a blessed change. It is time for applications to stop having a single data store – namely a relational database (probably Oracle) – and start using the best tool for the job.

In the last couple of years, since NOSQL technologies broke into our world, a lot of experience has been gathered on how to use them. Mainly, we see NoSQL technologies used for one of the following scenarios:

• Queries that require a very short response time
• Storing data without a well-defined schema, or storing data with a frequently modified schema

Now, I’m not in any way saying that NOSQL solutions are not used for other scenarios as well; I’m only saying that from our experience here at ScaleBase ,  these are the most common scenarios.

Other needs, like data backup, complex joins queries, consistent data storage – all are still being delivered by relational databases.

So the implementation is along the lines of a hybrid model – NOSQL for some tasks, MySQL (or other database, but MySQL is by far the most popular) for others.

ScaleBase is determined to assist in the relational database part of the problem, letting it scale and perform – just as the NOSQL side can scale and perform by itself (and frankly it can scale and perform very well, as this was the original requirement for most NOSQL solutions).

As NOSQL solutions grow in popularity and use, I expect we’ll see “design patterns” pop up – when to use relational databases and when to use NOSQL solutions (and of course – which one). For now, if you’re architecting your new web application/SaaS solution or social game – try to learn from the architectures of existing sites. You can get some at http://highscalability.com , and others at http://nosql.mypopescu.com/.

PlanetMySQL Voting: Vote UP / Vote DOWN

ScaleBase Releases Database TPC-C Performance Results

Technology achieves unprecedented transaction speed for a MySQL database at a low cost

 

Boston, Mass., December 12, 2011 – ScaleBase, Inc. today announced the results of its MySQL database benchmark, based on the industry-standard TPC-C test. ScaleBase has achieved an unmatched 180,000 Transactions per Minute – the highest result for a MySQL database – while running on an Amazon RDS environment. Cost per Transaction was reported to be 50 cents, which demonstrates the cost-effectiveness of the ScaleBase solution on the Amazon EC2 cloud. Full details of the benchmark can be found at http://www.scalebase.com/resources/performance/.

TPC, the Transaction Processing Performance Council, defines transaction processing and database benchmarks and delivers reliable, independent results to the industry. The TPC-C benchmark is a popular yardstick for comparing Online Transaction Processing (OLTP) performance on various hardware and software configurations.

The ScaleBase Database Load Balancer is a packaged solution for transparently scaling MySQL databases. ScaleBase utilizes two techniques for scaling: read-write splitting and transparent sharding (a technique for massively scaling-out relational databases). The software enables MySQL to scale transparently, without forcing developers to change a single line of code or perform a long data migration process. The technology is ideally suited for any application in which scalability, performance and speed are critical, including: gaming, e-commerce, SaaS, machine-generated data, Web 2.0 and more.

“Some people feel that by using MySQL they stand the chance of limiting their performance options, however, these TPC-C results proves that  this simply is no longer the case,” said Rob Levine, ScaleBase’s VP of Sales. “Without writing specialized code you can still get top performance – perhaps optimal performance – at an affordable rate, accounting for the requisite hardware and infrastructure resources. Especially in today’s economy, getting such great performance and optimizing every dollar spent can save companies substantial amounts of money.”

ScaleBase’s Database Load Balancer solution has been successfully used by numerous customers since its official release in August 2011.

 

About ScaleBase

ScaleBase has developed an innovative database load balancing technology that enables MySQL users to achieve scalability and high availability, without changing a single line of application code. ScaleBase utilizes two techniques for scaling: read-write splitting and transparent sharding, which is a method for massively scaling-out relational databases. The ScaleBase technology is ideally suited for any application in which scalability, performance and speed are critical, including: gaming, e-commerce, SaaS, machine-generated data and more. The company is privately-held and headquartered near Boston, Mass. Follow @SCLBase on Twitter.

 

Media Contact

Candice Perodeau

508-475-0025 x112

cperodeau@rainierco.com

PlanetMySQL Voting: Vote UP / Vote DOWN

On the download page you will find the executable for each SVN commit in the HeidiSQL repository. The executables are processed in conjunction with a SVN post commit hook. I just extended this process so it also creates the installer with that executable, using a InnoSetup command line. This way, users who need a full installer and also want to use the latest build can do that in one download.

Thanks to Jordan Russell for that excellent, free InnoSetup.
PlanetMySQL Voting: Vote UP / Vote DOWN

On the download page you will find the executable for each SVN commit in the HeidiSQL repository. The executables are processed in conjunction with a SVN post commit hook. I just extended this process so it also creates the installer with that executable, using a InnoSetup command line. This way, users who need a full installer and also want to use the latest build can do that in one download.

Thanks to Jordan Russell for that excellent, free InnoSetup.
PlanetMySQL Voting: Vote UP / Vote DOWN

There are several ways to implement sharding in your application. The first and by far the most popular, is to implement it inside your application. It can be implemented as part of your own Data Access Layer, database driver, or an ORM extension. However, there are many limitations with such implementation, which drove us, at ScaleBase, to look for an alternative architecture.

As the above diagram shows, ScaleBase is implemented as a standalone proxy. There are several benefits to using such an architecture.

First and foremost, since the sharding logic is not embedded inside the application, third party applications can be used, be it MySQL Workbench, MySQL command line interface or any other third party product. This translates to a huge saving in the day-to-day costs of both developers and system administrators.

Backup can be executed via the proxy, and so allows users to consistently backup a sharded environment – not an easy task when sharding is developed internally.

Since the application server machines are usually highly utilized (as they should be, to optimize costs), running additional code on application server machines will just slow them down. Running the code on external proxies allows for a more efficient division of tasks between the servers, and allows requests to be unaffected by data crunching (for instance cross-shard queries) requests.

So all in all there are many reasons to run sharding code outside the scope of the application and application server. If you’re interested – we’d love to chat.

PlanetMySQL Voting: Vote UP / Vote DOWN

Update: Thank you all for making this campaign a colossal success. We are extending this offer till Dec 2nd, 23:59 PST. Many corporate users requested us to extend the offer as they require time to get official approval. Pick your copy right now! Use coupon code blkfrdy11 to get 50% off.

–

Happy Thanksgiving!

Black Friday is back with a bang. Get a flat 50% discount on all Webyog products. Yes, you read it right, a flat fifty percent discount. Hurry, this offer expires Nov 28th Dec 2nd, 23:59 PST. Use coupon code blkfrdy11 to avail the discount on any purchase. Buy Now.

Still using SQLyog Community Edition?

Upgrade to the feature rich SQLyog Professional/Enterprise/Ultimate Edition. This offer is literally too good to pass up. Compare features.

Worried about your MySQL server’s health?

Monitor it like a PRO. Get MONyog – MySQL Monitor & Advisor. Your MySQL DBA in a box! Check what it has to offer.

Want to extend your maintenance period?

Don’t think twice, head right away to Customer Area & save a flat 50%. On extension, you get free access to all future releases of the respective products for one year.

Hurry, this offer expires Nov 28th Dec 2nd, 23:59 PST. Use coupon code blkfrdy11 to avail the discount on any purchase. Buy Now.

Regards,
Chirag
Webyog, Inc.

PlanetMySQL Voting: Vote UP / Vote DOWN

The ScaleBase Analysis tool gives a schema a grade between 1 and 100 for being “sharding compatible”. It’s a neat feature, but many ask me how the grade is calculated. Well – here goes.

First of all, a good schema is one that is easy to shard. Database Normalization is usually a good thing when sharding. It means that finding the sharding key is easy, relationships between tables are clear, and the queries themselves are usually much simpler. So we try to give a grade on how well the schema is normalized.

After the sharding configuration is determined (see here on how this should be done), we review your MySQL General Log, to understand the value you can expect from the sharding configuration:

• Statements that run on sharded tables, and hit a single shard.
  • Since each database is smaller in size, performance of a single shard improves. As a result, statements of this kind will give major performance improvements.
  • Bottom line – major performance improvement over the original configuration.
  • Statements that run on sharded tables, and hit multiple shards.
    • These statements run on multiple shards, in a map-reduce manner. It means they will run faster than running on a single, big, database – but they will run slower than statements that need to hit just one shard.
    • Bottom line – better performance than the original configuration.
    • Statements that run on global tables, and hit a single shard.
      • These are queries on global tables. Basically, the performance improvement should be similar to what’s seen on statements that run on a single shard (depending on the global table size of course).
      • Bottom line – major performance improvement over the original configuration.
      • Statements that run on global tables, and hit multiple shards.
        • DML operations over global tables need to hit all the shards. These will run slower than the original configuration, so if you see you have a lot of these, try to turn the specific global tables into split tables.

Sounds simple, right? Well, try to take all these parameters into consideration, and build a sharding configuration on your own. If you don’t want to – try out our ScaleBase Analyzer – for a free tool that can build the sharding configuration for you.

PlanetMySQL Voting: Vote UP / Vote DOWN

Users of MS SQL servers may find it useful to connect to their server via Windows authentication. The login dialog disables username + password in that case, as these are not required (indeed ignored by the server). The old option "Prompt for credentials" is now mutually exclusive to the new checkbox option "Windows authentication". Makes no sense to prompt for user+pass which then are ignored by the server. The connection dialog has grown a bit in its minimum height, as now the mentioned two checkboxes need vertical space. Well, features need space.



For MySQL sessions this checkbox is disabled. Although there is a MySQL server plugin which allows Windows authentication, the difference to MS SQL is that MySQL still asks for a username - only the password can be blank in that case.

Thanks to csiqojerncjsa for the hint on how to enable "Integrated Security" in a TAdoConnection
PlanetMySQL Voting: Vote UP / Vote DOWN

Wine users reported this a couple of times in HeidiSQL's bug tracker, and also on WineHQ there were several reports for the same thing found: black color on icon areas which should be transparent. Cosmetic though quite annoying for a GUI which provides important buttons on a main toolbar. Wine 1.3.33 says this is fixed now, as stated on WineHQ.
PlanetMySQL Voting: Vote UP / Vote DOWN